Project Home
Project Home
Trackers
Trackers
Documents
Documents
Wiki
Wiki
Discussion Forums
Discussions
Project Information
Project Info
Forum Topic - SIGSEGV using mudflap applications: (6 Items)
   
SIGSEGV using mudflap applications  
When attempting to debug an application which is instrumented using mudflap (e.g. -fmudflap during compile, with -
lmudflap during link), it seg faults in a basic printf() with the following stack dump:

Thread [1] (Suspended: Signal 'SIGSEGV' received. Description: Segmentation fault.)	
	19 _band_get_aligned()  0xfe328a0c	
	18 _band_get()  0xfe328b30	
	17 __malloc_lock()  0xfe32bd20	
	16 __malloc()  0xfe32c23c	
	15 malloc()  0xfe32b5a8	
	14 backtrace_symbols() \home\builder\hudson\gcc-trunk\svn\libmudflap\mf-runtime.c:1990 0xfe388e68	
	13 __mf_backtrace() \home\builder\hudson\gcc-trunk\svn\libmudflap\mf-runtime.c:2102 0xfe38903c	
	12 __mfu_register() \home\builder\hudson\gcc-trunk\svn\libmudflap\mf-runtime.c:1074 0xfe38a0a8	
	11 __mf_register() \home\builder\hudson\gcc-trunk\svn\libmudflap\mf-runtime.c:1174 0xfe38a1e8	
	10 malloc() \home\builder\hudson\gcc-trunk\svn\libmudflap\mf-hooks1.c:126 0xfe38bacc	
	9 _Fbuf()  0xfe356c64	
	8 _Fwprep()  0xfe357404	
	7 fwrite()  0xfe354c2c	
	6 _Fprout()  0xfe356ed4	
	5 _Printf()  0xfe35a63c	
	4 vprintf()  0xfe35648c	
	3 __mfwrap_printf() \home\builder\hudson\gcc-trunk\svn\libmudflap\mf-hooks2.c:1019 0xfe392444	
	2 usage() c:\code\keystone\src\embed\ttdk\Util\devices\src\device.c:293 0x480423d8	
	1 main() c:\code\keystone\src\embed\ttdk\Util\devices\src\device.c:1015 0x4804bba8	


But when running the applicaiton directly from the console with the same environment settings, it runs just fine.

I've tried using the IDE tool for displaying the mudflap output, as well as just adding the MUDFLAP_OPTIONS environment 
variable.

Anyone else seen this?

Thanks,

Bob
Re: SIGSEGV using mudflap applications  
Is your app multithreaded? What happens if you press continue after 
SIGSEGV is received?

Robert Burns wrote:
> When attempting to debug an application which is instrumented using mudflap (e.g. -fmudflap during compile, with -
lmudflap during link), it seg faults in a basic printf() with the following stack dump:
>
> Thread [1] (Suspended: Signal 'SIGSEGV' received. Description: Segmentation fault.)	
> 	19 _band_get_aligned()  0xfe328a0c	
> 	18 _band_get()  0xfe328b30	
> 	17 __malloc_lock()  0xfe32bd20	
> 	16 __malloc()  0xfe32c23c	
> 	15 malloc()  0xfe32b5a8	
> 	14 backtrace_symbols() \home\builder\hudson\gcc-trunk\svn\libmudflap\mf-runtime.c:1990 0xfe388e68	
> 	13 __mf_backtrace() \home\builder\hudson\gcc-trunk\svn\libmudflap\mf-runtime.c:2102 0xfe38903c	
> 	12 __mfu_register() \home\builder\hudson\gcc-trunk\svn\libmudflap\mf-runtime.c:1074 0xfe38a0a8	
> 	11 __mf_register() \home\builder\hudson\gcc-trunk\svn\libmudflap\mf-runtime.c:1174 0xfe38a1e8	
> 	10 malloc() \home\builder\hudson\gcc-trunk\svn\libmudflap\mf-hooks1.c:126 0xfe38bacc	
> 	9 _Fbuf()  0xfe356c64	
> 	8 _Fwprep()  0xfe357404	
> 	7 fwrite()  0xfe354c2c	
> 	6 _Fprout()  0xfe356ed4	
> 	5 _Printf()  0xfe35a63c	
> 	4 vprintf()  0xfe35648c	
> 	3 __mfwrap_printf() \home\builder\hudson\gcc-trunk\svn\libmudflap\mf-hooks2.c:1019 0xfe392444	
> 	2 usage() c:\code\keystone\src\embed\ttdk\Util\devices\src\device.c:293 0x480423d8	
> 	1 main() c:\code\keystone\src\embed\ttdk\Util\devices\src\device.c:1015 0x4804bba8	
>
>
> But when running the applicaiton directly from the console with the same environment settings, it runs just fine.
>
> I've tried using the IDE tool for displaying the mudflap output, as well as just adding the MUDFLAP_OPTIONS 
environment variable.
>
> Anyone else seen this?
>
> Thanks,
>
> Bob
>
>
>
> _______________________________________________
>
> QNX Momentics Community Support
> http://community.qnx.com/sf/go/post34237
>
>   
Re: SIGSEGV using mudflap applications  
> Is your app multithreaded? What happens if you press continue after 
> SIGSEGV is received?
> 

The app is not multi-threaded and pressing continue results in termination of the program (simillar to what would happen
 if you had a real SIGSEGV problem).

Seems odd to me to have the SIGSEGV so low in the internals when running in the debugger, but not when running from the 
console.

Thanks,

Bob
Re: SIGSEGV using mudflap applications  
Btw. Do you use IDE to debug? If so please uncheck "Use unique name" in 
Upload tab of launch configuration. It was a bug in 6.4.0 mudflap 
library that makes it crash.

Robert Burns wrote:
>> Is your app multithreaded? What happens if you press continue after 
>> SIGSEGV is received?
>>
>>     
>
> The app is not multi-threaded and pressing continue results in termination of the program (simillar to what would 
happen if you had a real SIGSEGV problem).
>
> Seems odd to me to have the SIGSEGV so low in the internals when running in the debugger, but not when running from 
the console.
>
> Thanks,
>
> Bob
>
>
>
> _______________________________________________
>
> QNX Momentics Community Support
> http://community.qnx.com/sf/go/post34262
>
>   
Re: SIGSEGV using mudflap applications  
> Btw. Do you use IDE to debug? If so please uncheck "Use unique name" in 
> Upload tab of launch configuration. It was a bug in 6.4.0 mudflap 
> library that makes it crash.
> 

Yes indeed I was using the debugger, and that did the trick!  BTW I'm using 6.4.1, so this must have carried forward 
into 6.4.1.

Thanks for the help -- much appreciated.

Bob
Re: SIGSEGV using mudflap applications  
> Btw. Do you use IDE to debug? If so please uncheck "Use unique name" in 
> Upload tab of launch configuration. It was a bug in 6.4.0 mudflap 
> library that makes it crash.
> 

I have the same problem, unique name is uncheck though ;-(  The program only crashed when I use mudflap. it crashed 
before main()..  Could be cause by the C++ constructor of a global variable.

Thread [1] (Suspended: Signal 'SIGSEGV' received. Description: Segmentation fault.)	
	28 _band_get_aligned()  0xb03273f6	
	27 _band_get()  0xb032745c	
	26 __malloc_lock()  0xb032a10f	
	25 __malloc()  0xb032a604	
	24 malloc()  0xb0329abd	
	23 backtrace_symbols() /home/builder/hudson/gcc-trunk/svn/libmudflap/mf-runtime.c:1990 0xb86c5225	
	22 __mf_backtrace() /home/builder/hudson/gcc-trunk/svn/libmudflap/mf-runtime.c:2102 0xb86c533c	
	21 __mf_violation() /home/builder/hudson/gcc-trunk/svn/libmudflap/mf-runtime.c:2189 0xb86c5ab7	
	20 __mfu_check() /home/builder/hudson/gcc-trunk/svn/libmudflap/mf-runtime.c:1044 0xb86c6b3f	
	19 __mf_check() /home/builder/hudson/gcc-trunk/svn/libmudflap/mf-runtime.c:823 0xb86c6cdb	
	18 std::string::_Myptr() /opt/qnx641/target/qnx6/usr/include/cpp/xstring:1683 0x0807d161	
	17 std::string::_Eos() /opt/qnx641/target/qnx6/usr/include/cpp/xstring:1628 0x0808063c	
	16 std::string::_Tidy() /opt/qnx641/target/qnx6/usr/include/cpp/xstring:1674 0x08080993	
	15 basic_string() /opt/qnx641/target/qnx6/usr/include/cpp/xstring:453 0x080820e7	
	14 <symbol is not available> 0xb85b3cf2	
	13 <symbol is not available> 0xb8657fb4	
	12 <symbol is not available> 0xb86091c5	
	11 <symbol is not available> 0xb8603e1b	
	10 <symbol is not available> 0xb86558ac	
	9 <symbol is not available> 0xb865043c	
	8 <symbol is not available> 0xb84bf770	
	7 <symbol is not available> 0x08046c34	
	6 <symbol is not available> 0xb86048ee	
	5 <symbol is not available> 0xb0377108	
	4 <symbol is not available> 0x0830c500	
	3 <symbol is not available> 0x08046d28	
	2 <symbol is not available> 0xb84bf77a	
	1 init()  0xb033fafa