[m-dev.] hang-up in C-code in asm_fast.gc.prof

Julien Fischer juliensf at csse.unimelb.edu.au
Thu May 24 16:02:52 AEST 2007

On Thu, 24 May 2007, Ondrej Bojar wrote:

> Hi, everyone.
> I'm not quite confident to call this a bug, so I'm posting it rather to 
> merc-devel.
> I compiled my code using rotd-2007-05-20. The code runs fine in asm_fast.gc 
> but hangs up (I previously thought it 'loops ad infinitum') if compiled in 
> asm_fast.gc.prof.
> What actually happens is that my mercury code calls come C-code and the 
> C-code tries to remove a temporary file using a system call. (Don't ask me 
> why simple unlink is not used instead, it's not my code.)
> Here is a gdb trace, unfortunately I still don't have the runtime compiled 
> with debugging information.
> If I understand it correctly, a profiler tick happens at the call to 
> system(cmd). After some further steps within the profiler, a do_system in 
> libc is called and hangs forever.
> Breakpoint 1, removefile (filePath=@0x7fff43730500) at util.cpp:51
> 51        sprintf(cmd,"rm %s",filePath.c_str());
> Current language:  auto; currently c++
> (gdb) print filePath
> $1 = (const string &) @0x7fff43730500: {static npos = 18446744073709551615,
>  _M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = 
> {<No data fields>}, <No data fields>}, _M_p = 0x6ca7e078 
> "/tmp/dskbuff--IpMvxN"}}
> (gdb) step
> 52        system(cmd);
> (gdb) step
> prof_handle_tick (signum=27) at mercury_prof.c:199
> 199     mercury_prof.c: No such file or directory.
>        in mercury_prof.c
> Current language:  auto; currently c
> (gdb) step
> 207     in mercury_prof.c
> (gdb) step
> 213     in mercury_prof.c
> (gdb) finish
> Run till exit from #0  prof_handle_tick (signum=27) at mercury_prof.c:223
> <signal handler called>
> (gdb) step
> Single stepping until exit from function __restore_rt,
> which has no line number information.
> 0x00000037a6d3ac50 in system () from /lib64/libc.so.6
> (gdb) step
> Single stepping until exit from function system,
> which has no line number information.
> 0x00000037a6d3a7f0 in do_system () from /lib64/libc.so.6
> (gdb) step
> Single stepping until exit from function do_system,
> which has no line number information.
> <hangs forever>
> Any ideas whose fault is this? Any secure means to prevent that?

The benchmarking module contains some predicates to turn profiling on and 
off.  What happens if you disable profiling before your system call and
enable it afterwards?  (I know that defeats the purpose of profiling,
but ...)

mercury-developers mailing list
Post messages to:       mercury-developers at csse.unimelb.edu.au
Administrative Queries: owner-mercury-developers at csse.unimelb.edu.au
Subscriptions:          mercury-developers-request at csse.unimelb.edu.au

More information about the developers mailing list