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

[Ondrej Bojar]

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?

Thanks, Ondrej.

--------------------------------------------------------------------------
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
--------------------------------------------------------------------------