Bug 115562 - mono crashes when run under valgrind
Summary: mono crashes when run under valgrind
Status: REPORTED
Alias: None
Product: valgrind
Classification: Developer tools
Component: general (show other bugs)
Version: 3.1 SVN
Platform: Compiled Sources Linux
: NOR major
Target Milestone: ---
Assignee: Julian Seward
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-11-02 20:22 UTC by Matt Hargett
Modified: 2009-06-08 12:08 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
simple testcase to reproduce the problem (191 bytes, application/octet-stream)
2009-06-01 13:07 UTC, Timo Lindfors
Details
output of valgrind-3.4.1 mono ./hello.exe (20.63 KB, application/octet-stream)
2009-06-08 12:07 UTC, Timo Lindfors
Details
output of valgrind-3.4.1 --smc-check=all mono ./hello.exe (20.79 KB, application/octet-stream)
2009-06-08 12:08 UTC, Timo Lindfors
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Matt Hargett 2005-11-02 20:22:31 UTC
When running mono under valgrind, mono crashes early in it's initialization. 
When not running it under valgrind, it doesn't crash. This is with mono SVN and 
valgrind 3.1 SVN as of 11/2/2005 on x86-64, linux 2.6.13, with gcc 3.4.4 and 
glibc 2.3.5. I also tested with mono 1.1.9 and the same problem occurs there 
also. 
 
==7357== Process terminating with default action of signal 11 (SIGSEGV) 
==7357==  Access not within mapped region at address 0x7FF001000 
==7357==    at 0x4BCBD8: GC_push_all_eager (mark.c:1468) 
==7357==    by 0x4C36EE: pthread_push_all_stacks (pthread_stop_world.c:266) 
==7357==    by 0x4BD49B: GC_mark_some (mark.c:326) 
==7357==    by 0x4B6C24: GC_stopped_mark (alloc.c:533) 
==7357==    by 0x4B7541: GC_try_to_collect_inner (alloc.c:375) 
==7357==    by 0x4BEC95: GC_init_inner (misc.c:782) 
==7357==    by 0x4BEE36: GC_init (misc.c:492) 
==7357==    by 0x4E53CA: mini_init (mini.c:10184) 
==7357==    by 0x418F3C: mono_main (driver.c:845) 
==7357==    by 0x5442CFF: __libc_start_main (in /lib/libc-2.3.5.so) 
==7357==    by 0x418859: ??? (start.S:113) 
==7357== Process terminating with default action of signal 11 (SIGSEGV) 
==7357==  Access not within mapped region at address 0x7FF001000 
==7357==    at 0x4BCBD8: GC_push_all_eager (mark.c:1468) 
==7357==    by 0x4C36EE: pthread_push_all_stacks (pthread_stop_world.c:266) 
==7357==    by 0x4BD49B: GC_mark_some (mark.c:326) 
==7357==    by 0x4B6C24: GC_stopped_mark (alloc.c:533) 
==7357==    by 0x4B7541: GC_try_to_collect_inner (alloc.c:375) 
==7357==    by 0x4BEC95: GC_init_inner (misc.c:782) 
==7357==    by 0x4BEE36: GC_init (misc.c:492) 
==7357==    by 0x4E53CA: mini_init (mini.c:10184) 
==7357==    by 0x418F3C: mono_main (driver.c:845) 
==7357==    by 0x5442CFF: __libc_start_main (in /lib/libc-2.3.5.so) 
==7357==    by 0x418859: ??? (start.S:113)
Comment 1 Julian Seward 2005-11-03 15:17:00 UTC
This might be to do with the Boehm GC.  What happens if you persuade
it not to run?
Comment 2 Timo Lindfors 2009-06-01 13:07:13 UTC
Created attachment 34164 [details]
simple testcase to reproduce the problem

This seems to occur even with the simplest testcase and even garbage collection is disabled with export GC_DONT_GC=1.

Steps to reproduce:
1) mcs1 hello.cs
2) valgrind mono ./hello.exe

Expected results:
2) program prints Hello world

Actual results:
2) program prints Hello world but also

==31586== Memcheck, a memory error detector.
==31586== Copyright (C) 2002-2008, and GNU GPL'd, by Julian Seward et al.
==31586== Using LibVEX rev 1884, a library for dynamic binary translation.
==31586== Copyright (C) 2004-2008, and GNU GPL'd, by OpenWorks LLP.
==31586== Using valgrind-3.4.1, a dynamic binary instrumentation framework.
==31586== Copyright (C) 2000-2008, and GNU GPL'd, by Julian Seward et al.
==31586== For more details, rerun with: -v
==31586== 
Hello World
--31586-- VALGRIND INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) - exiting
--31586-- si_code=1;  Faulting address: 0xFCC;  sp: 0x40308bfc0

valgrind: m_signals.c:1929 (sync_signalhandler): Assertion 'tid != 0' failed.
==31586==    at 0x38053648: report_and_quit (m_libcassert.c:140)
==31586==    by 0x40308B740: ???
==31586==    by 0x30382152B5: ???
==31586==    by 0x38055737: add_to_myprintf_buf (m_libcprint.c:91)
==31586==    by 0x40308B740: ???
==31586==    by 0x380E8B61: myvprintf_str (m_debuglog.c:467)
==31586==    by 0x3000000000: ???
==31586==    by 0x400000008: ???
==31586==    by 0x40308B6A0: ???
==31586==    by 0x4F: ???
==31586==    by 0x4F: ???

sched status:
  running_tid=2

Thread 2: status = VgTs_Runnable
==31586==    at 0x5C9CE70: (within /lib/libc-2.7.so)
==31586==    by 0x5C9CC58: (within /lib/libc-2.7.so)
==31586==    by 0x5C9D371: (within /lib/libc-2.7.so)
==31586==    by 0x4A1D95E: _vgnU_freeres (vg_preloaded.c:60)

More info:
1) valgrind 3.4.1
2) mcs 1.9.1.10
3) debian stable
4) Intel(R) Core(TM)2 Quad CPU    Q6600  @ 2.40GHz
5) Linux overlord2 2.6.26-2-amd64 #1 SMP Wed May 13 15:37:46 UTC 2009 x86_64 GNU/Linux
Comment 3 Tom Hughes 2009-06-01 13:47:37 UTC
It seems to be fine for me on F10 with mono-core-2.2-1.fc10.x86_64 with or without GC turned on (though GC produces lots more warnings obviously).
Comment 4 Julian Seward 2009-06-02 02:29:07 UTC
Does --smc-check=all help?
Comment 5 Timo Lindfors 2009-06-08 11:44:26 UTC
Sorry, I can only reproduce this with valgrind 3.4.1 release. I don't get internal error with svn revision 10274 (vex 1899).
Comment 6 Julian Seward 2009-06-08 11:50:24 UTC
Please give a clear answer to Comment #4:
With 3.4.1, does --smc-check=all help, or not?
Comment 7 Timo Lindfors 2009-06-08 12:07:07 UTC
Created attachment 34363 [details]
output of valgrind-3.4.1 mono ./hello.exe
Comment 8 Timo Lindfors 2009-06-08 12:08:41 UTC
Created attachment 34364 [details]
output of valgrind-3.4.1 --smc-check=all mono ./hello.exe

As you can see from this log file valgrind 3.4.1 hits the assertion even with --smc-check=all