[Top][All Lists]

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

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

From: Garrett Cooper
Subject: Re: Segfault with make-3.81 on OSX Leopard x86(_64)
Date: Tue, 6 May 2008 12:42:07 -0700

On May 6, 2008, at 11:14 AM, Tom Honermann wrote:

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

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");
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..


A vanilla copy of gmake compiled by moi worked perfectly fine with gcc 4.0.1 with stock options (CFLAGS=-g only). I'm going to take up the issue with Apple and see if I can better reproduce the issue.
Thanks for the suggestions :).

reply via email to

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