bug-make
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Segfault with make-3.81 on OSX Leopard x86(_64)


From: Tom Honermann
Subject: Re: Segfault with make-3.81 on OSX Leopard x86(_64)
Date: Tue, 06 May 2008 11:14:17 -0700
User-agent: Mozilla Thunderbird 1.0 (Windows/20041206)

Garrett Cooper wrote:
On May 6, 2008, at 4:56 AM, Paul Smith wrote:

On Tue, 2008-05-06 at 01:09 -0700, Garrett Cooper wrote:
Trying to compile ltp (ltp.sf.net) with modified makefiles and
whenever I run make as follows, it segfaults:

-------------------
shiina:ltp-full-20080430 gcooper$ make -Np
Segmentation fault

Hm.  I can't reproduce this; it doesn't segfault on my GNU/Linux  system.
Checking with valgrind doesn't yield any obvious suspicious things  going
on.

Can you get a stack trace?  I don't know if OSX comes with GDB, but if
so you can do something like:

 gdb make
    ...
 (gdb) run -Np
    ...
 (gdb) bt

Tricky enough it appears to only be with OSX, and it may be syscall  related. I installed F8 with VMware fusion and the stinker appears to  be passing without issue. There might have been a patchset involved  with the F8 gmake though...

shiina:~ gcooper$ gdb make
GNU gdb 6.3.50-20050815 (Apple version gdb-768) (Tue Oct  2 04:07:49  UTC 2007)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and  you are
welcome to change it and/or distribute copies of it under certain  conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for  details.
This GDB was configured as "i386-apple-darwin"...Reading symbols for  shared libraries ... done

(gdb) set arg -Np
(gdb) run
Starting program: /usr/bin/make -Np
Reading symbols for shared libraries ++. done

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x65726e50
0x91fc3690 in strlen ()
(gdb) bt
#0  0x91fc3690 in strlen ()
#1  0x91fbd2d1 in __vfprintf ()
#2  0x91fbbbb6 in __vfprintf ()
#3  0x91ff11e3 in vfprintf_l ()
#4  0x91ff1177 in fprintf ()
#5  0x0000f472 in ?? ()
#6  0x0000de5f in ?? ()
#7  0x000017be in ?? ()
I've often seen call stacks like this (in other products) due to code like:
const char* value = getenv("VAR");
printf(value);
If value points to a string with a '%s' in it, you will get unpredictable behavior (often problems in a call to 'strlen()').  The corrected code would be:
const char* value = getenv("VAR");
printf("%s", value);

Were there any known issues with gmake compiled with gcc 4.0.1?

I'm going to try prodding Apple in the meantime though and see what  comes up..

Thanks,
-Garrett


_______________________________________________
Bug-make mailing list
address@hidden
http://lists.gnu.org/mailman/listinfo/bug-make

reply via email to

[Prev in Thread] Current Thread [Next in Thread]