Strsep在我的Mac OS X x86_64系统上返回32位指针

Question

Edit: Found solution (see bottom)

I'm trying to build a software package ( owfs ) on a Mac OS X 10.8 x86_64 system. This software package is mostly developed on/for linux, but I've gotten an old version to compile and function correctly, and there are plenty of posts around the internet of people running various versions of it, so I'm hopeful that it's possible. I've been able to get the compilation process to complete successfully, but the program segfaults when I try to run it. I investigated in GDB, and here is what I found:

The offending piece of code:

void FS_dir_entry_aliased(void (*dirfunc) (void *, const struct parsedname *), void *v, const struct parsedname *pn)
{
if ( ( pn->state & ePS_unaliased ) == 0 ) {
    // Want alias substituted
    struct parsedname s_pn_copy ;
    struct parsedname * pn_copy = & s_pn_copy ;

    ASCII path[PATH_MAX+3] ;
    ASCII * path_pointer = path ; // current location in original path

    // Shallow copy
    memcpy( pn_copy, pn, sizeof(struct parsedname) ) ;
    pn_copy->path[0] = '\0' ;

    // path copy to use for separation
    strcpy( path, pn->path ) ;

    // copy segments of path (delimitted by "/") to copy
    while( path_pointer != NULL ) {
                    ASCII * path_segment = NULL;
        path_segment = strsep( &path_pointer, "/" ) ;
        BYTE sn[SERIAL_NUMBER_SIZE] ;

        if ( PATH_MAX < strlen(pn_copy->path) + strlen(path_segment) ) {

The call to strlen(path_segment) in the if block fails because path_segment is an out-of-bounds address.

Taking things step by step with GDB, here's what I've found. Going into the call that initializes path_segment with strsep , gdb gives me:

path_pointer = (ASCII *) 0x7fff5fbf99a5 "/uncached/bus.0/interface"

After I execute the next line, path_pointer has advanced, as I would expect:

path_pointer = (ASCII *) 0x7fff5fbf99a6 "uncached/bus.0/interface"

but gdb reports:

path_segment = (ASCII *) 0x5fbf99a5 <Address 0x5fbf99a5 out of bounds>

This is the correct "start" of the address, but it's a 32-bit pointer address. Since my system is a 64-bit system, when strlen gets called on this, I get a EXC_BAD_ACCESS.

I understand there's a lot going on here, and I haven't provided enough info if the problem is something buried deeply in the package build process. It seems to me though that this might have a simple solution, since the function is basically working correctly, but just returning the wrong size pointer. I have very little experience with the intricacies of 64 bit vs. 32 bit systems though, so I was wondering if anyone can spot something obvious, or provide instructions for next steps debugging this issue. Interestingly, when I run the strsep commands by hand in gdb ( p (ASCII *) strsep (&path_pointer, "/") ), they appear to work fine, giving me 64 bit pointers that match what I expect them to.

Finally, in case it's useful, here's what I believe are the assembly lines for the strsep call:

0x0000000100036eee <FS_dir_entry_aliased+318>:  callq  0x1000a56a0 <dyld_stub_strsep>
0x0000000100036ef3 <FS_dir_entry_aliased+323>:  mov    %eax,%ecx
0x0000000100036ef5 <FS_dir_entry_aliased+325>:  movslq %ecx,%rcx
0x0000000100036ef8 <FS_dir_entry_aliased+328>:  mov    %rcx,-0x1d10(%rbp)

and the disassemble for the strsep that's at that callq address:

0x00007fff915c0fc7 <strsep+0>:  push   %rbp
0x00007fff915c0fc8 <strsep+1>:  mov    %rsp,%rbp
0x00007fff915c0fcb <strsep+4>:  mov    (%rdi),%r8
0x00007fff915c0fce <strsep+7>:  xor    %eax,%eax
0x00007fff915c0fd0 <strsep+9>:  test   %r8,%r8
0x00007fff915c0fd3 <strsep+12>: je     0x7fff915c1007 <strsep+64>
0x00007fff915c0fd5 <strsep+14>: mov    %r8,%r10
0x00007fff915c0fd8 <strsep+17>: jmp    0x7fff915c0fe4 <strsep+29>
0x00007fff915c0fda <strsep+19>: inc    %rdx
0x00007fff915c0fdd <strsep+22>: test   %al,%al
0x00007fff915c0fdf <strsep+24>: jne    0x7fff915c0fee <strsep+39>
0x00007fff915c0fe1 <strsep+26>: mov    %r9,%r10
0x00007fff915c0fe4 <strsep+29>: mov    (%r10),%cl
0x00007fff915c0fe7 <strsep+32>: lea    0x1(%r10),%r9
0x00007fff915c0feb <strsep+36>: mov    %rsi,%rdx
0x00007fff915c0fee <strsep+39>: mov    (%rdx),%al
0x00007fff915c0ff0 <strsep+41>: cmp    %cl,%al
0x00007fff915c0ff2 <strsep+43>: jne    0x7fff915c0fda <strsep+19>
0x00007fff915c0ff4 <strsep+45>: xor    %edx,%edx
0x00007fff915c0ff6 <strsep+47>: test   %cl,%cl
0x00007fff915c0ff8 <strsep+49>: je     0x7fff915c1001 <strsep+58>
0x00007fff915c0ffa <strsep+51>: movb   $0x0,(%r10)
0x00007fff915c0ffe <strsep+55>: mov    %r9,%rdx
0x00007fff915c1001 <strsep+58>: mov    %rdx,(%rdi)
0x00007fff915c1004 <strsep+61>: mov    %r8,%rax
0x00007fff915c1007 <strsep+64>: pop    %rbp
0x00007fff915c1008 <strsep+65>: retq

Edit: string.h is definitely being included, there's a system-wide include file that includes it, but just to make sure I tried adding it this specific file. -D_BSD_SOURCE=1 is one of the compiler options added automatically, so that is happening. There is also a compiler option -D_ISOC99_SOURCE=1 by default. I tried adding -std=gnu99 (my compiler, llvm-gcc 4.2, doesn't like -std=gnu90 ), but it did not fix it. I'm getting the following compiler errors:

Here are the compiler warnings that I get for this file:

ow_alias.c: In function 'ReadAliasFile':
ow_alias.c:40: warning: implicit declaration of function 'getline'
ow_alias.c:48: warning: implicit declaration of function 'strsep'
ow_alias.c:48: warning: assignment makes pointer from integer without a cast
ow_alias.c:64: warning: assignment makes pointer from integer without a cast
ow_alias.c: In function 'FS_dir_entry_aliased':
ow_alias.c:177: warning: initialization makes pointer from integer without a cast

Second Edit: After doing a little more digging (thanks for the gcc -E | grep strsep tip!), I found the problem was with a compiler flag -D_POSIX_C_SOURCE=200112L . This compiler flag was blocking the definition of strsep, making the compiler make an implicit declaration. I removed this from the configure script and everything seems to be working fine. Thanks for the help!

Answer 1

You need to make sure that string.h is included.

If that's already being done, you'll need to also define a feature test macro to enable the declaration of strsep() . Adding -D_GNU_SOURCE or -D_BSD_SOURCE should do the trick. However, you might want to look into how you have things configured right now - _BSD_SOURCE is usually enabled by default. Perhaps you're telling gcc to compile with -std=c90 or -std=c99 , which will turn off many feature test macros. Use -std=gnu90 or -std=gnu99 instead.

Are you seeing warnings such as "initialization makes pointer from integer without a cast" or "implicit declaration of function"?