bugGNUstep - Bugs: bug #13800, link/dependency order issue (e.g....

Group
 
 

bug #13800: link/dependency order issue (e.g. amd64-unknown-freebsd7.0)

Submitter:  David Ayers <ayers>
Submitted:  Thu 14 Jul 2005 10:33:13 AM UTC
   
 
Category:  Makefiles Severity:  3 - Normal
Item Group:  Bug Status:  Invalid
Privacy:  Public Assigned to:  None
Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Wed 16 Jan 2013 08:28:14 AM UTC, comment #6: 

Is this bug still valid? not only we are at FReeBSD 8.x and 9.x, buit quite some changes were done in threading since 2007.

Riccardo Mottola <rmottola>
Group Member
Sun 18 Mar 2007 10:08:41 AM UTC, comment #5: 

Call for status report...

Does anyone know if FreeBSD's pthread implementation has been fixed with respect to reliably initialzing its internal data (specficially guarding pthread_key_create() with _libpthread_init())?

If not, could someone FreeBSD user/developer point this bug report to a FreeBSD bug report so we can close this issue here?

Thanks!
David

David Ayers <ayers>
Group Member
Fri 15 Jul 2005 06:44:40 PM UTC, comment #4: 

I'll take your analysis and present it to the FreeBSD-threads list in the hope that pointing out the missing guarding of pthread_key_create() ... hopefully we can get this issue fixed that way.

Thanks for taking the time to more thoroughly do this analysis than i could have done myself.

I'll try to keep this bug up to date with resolution information when/if available.

As far as how this affects FreeBSD-RELEASE versions ... i am about 99% sure the exact same issue Will be present there as well.

Pascal Hofstee <caelian>
Fri 15 Jul 2005 09:29:55 AM UTC, comment #3: 

Thank you Pascal for the debug versions of libobjc and libpthread.  Here is my final analysis:

The real bug does indeed lie in the internal initialization process of the FreeBSD libpthread library.  In this case when libobjc is not excplitly linked into the executable, (and is further at the bottom of the ldd depenency list) it get's initialized before libpthread does.  i.e. it starts calling libpthread functions before the following constructor:

void    thread_init_hack(void) __attribute_ ((constructor));

void
_thread_init_hack(void)
{

        _libpthread_init(NULL);
}

of the libpthread library is called.  This constructor sets up the data structures for _get_curthread().

The function that libobjc calls early:
pthread_key_create() calls _get_currthread which still returns NULL.  This pointer is then dereferenced in the THR_LOCK_ACQUIRE macro resulting in the segfault.

Many of the mutex functions have already been guarded for this case with the following code fragements:

        if (_thr_initial == NULL)
                _libpthread_init(NULL);

See also the following comment in thr_create.c:
...

  • Some notes on new thread creation and first time initializion
  • to enable multi-threading.

 *

  • There are basically two things that need to be done.

 *

  •   1) The internal library variables must be initialized.
  •   2) Upcalls need to be enabled to allow multiple threads
  •      to be run.

 *

  • The first may be done as a result of other pthread functions
  • being called.  When _thr_initial is null, _libpthread_init is
  • called to initialize the internal variables; this also creates
  • or sets the initial thread.  It'd be nice to automatically
  • have _libpthread_init called on program execution so we don't
  • have to have checks throughout the library.

...

So they seem to be aware of the issue but haven't guarded all functions like pthread_key_create() which libobjc calls.

I don't believe that we can find a reliable workaround within GNUstep.  I also don't know if this bug is in a stable release version of FreeBSD.  But I want to mention that a call to pthread_self() would workaround this.  Yet this call would have to be done in libobjc's __objc_init_thread_system and not in GNUstep.  The other hack is to fiddle with the link order so that the constructor above can cover up the issue.

I'll leave it up to the -make maintainers to decide what to do.  My current tendency is to close this bug as invalid at least until someone verifies that the issue exists with released versions of FreeBSD.  And even then a workaround should probably  be done in libobjc (which seems to be installed by FreeBSD but if libobjc needs updating you might as well update libpthread instead and fix the bug properly).

Cheers,
David

David Ayers <ayers>
Group Member
Thu 14 Jul 2005 11:53:10 AM UTC, comment #2: 

Nope... but merely adding -lobjc in any order wrt -pthread does:
ayers@synergy$ gcc -rdynamic -o shared_debug_obj/plparse ./shared_debug_obj/plparse.o -L../Source/./shared_debug_obj -L/home/ayers/GNUstep/Library/Libraries -L/home/ayers/GNUstep/Local/Library/Libraries -L/home/ayers/GNUstep/System/Library/Libraries -L/usr/local/lib -lgnustep-base_d -pthread
ayers@synergy$ ./obj/plparse
Segmentation fault: 11 (core dumped)
ayers@synergy$ gcc -rdynamic -o shared_debug_obj/plparse ./shared_debug_obj/plparse.o -L../Source/./shared_debug_obj -L/home/ayers/GNUstep/Library/Libraries -L/home/ayers/GNUstep/Local/Library/Libraries -L/home/ayers/GNUstep/System/Library/Libraries -L/usr/local/lib -lgnustep-base_d -pthread -lobjc
ayers@synergy$ ./obj/plparse
No file names given to parse.
ayers@synergy$ gcc -rdynamic -o shared_debug_obj/plparse ./shared_debug_obj/plparse.o -L../Source/./shared_debug_obj -L/home/ayers/GNUstep/Library/Libraries -L/home/ayers/GNUstep/Local/Library/Libraries -L/home/ayers/GNUstep/System/Library/Libraries -L/usr/local/lib -lgnustep-base_d -lobjc -pthread
ayers@synergy$ ./obj/plparse
No file names given to parse.
ayers@synergy$

David Ayers <ayers>
Group Member
Thu 14 Jul 2005 11:13:13 AM UTC, comment #1: 

Would simply putting -pthread at the end of the compile command (rather than at the beginning) fix it ?

Thanks

Nicola Pero <nico>
Group Member
Thu 14 Jul 2005 10:33:13 AM UTC, original submission:  

OK, I now have access to the amd64-unknown-freebsd7.0 box and it seems the issue is a link ordering issue.  Let's look at plparse as an example.

by default plparse is linked via:
gcc  -rdynamic      -pthread -o shared_debug_obj/plparse \
        ./shared_debug_obj/plparse.o \
         -L../Source/./shared_debug_obj -L/home/ayers/GNUstep/Library/Libraries -L/home/ayers/GNUstep/Local/Library/Libraries -L/home/ayers/GNUstep/System/Library/Libraries -L/usr/local/lib -lgnustep-base_d

ldd shows:
obj/plparse:
        libgnustep-base_d.so.1.10 => /home/ayers/GNUstep/System/Library/Libraries/libgnustep-base_d.so.1.10 (0x80062e000)
        libpthread.so.1 => /usr/lib/libpthread.so.1 (0x800b8c000)
        libc.so.6 => /lib/libc.so.6 (0x800cb7000)
        libobjc.so.1 => /usr/lib/libobjc.so.1 (0x800ebc000)
        libgmp.so.6 => /usr/local/lib/libgmp.so.6 (0x800fd7000)
        libxslt.so.2 => /usr/local/lib/libxslt.so.2 (0x80110c000)
        libxml2.so.5 => /usr/local/lib/libxml2.so.5 (0x801243000)
        libz.so.2 => /lib/libz.so.2 (0x801482000)
        libiconv.so.3 => /usr/local/lib/libiconv.so.3 (0x801595000)
        libm.so.3 => /lib/libm.so.3 (0x801788000)
        libkvm.so.2 => /lib/libkvm.so.2 (0x8018a8000)

this version segfaults during the thread system setup. (Sorry, no debug version of libobjc and libpthread yet, so no further info on the actual reason of the segfault.)

But if I manually execute the link command above appending '-lobjc' ldd reports:
obj/plparse:         libgnustep-base_d.so.1.10 => /home/ayers/GNUstep/System/Library/Libraries/libgnustep-base_d.so.1.10 (0x80062e000)
        libobjc.so.1 => /usr/lib/libobjc.so.1 (0x800b8c000)
        libpthread.so.1 => /usr/lib/libpthread.so.1 (0x800ca7000)
        libc.so.6 => /lib/libc.so.6 (0x800dd2000)
        libgmp.so.6 => /usr/local/lib/libgmp.so.6 (0x800fd7000)
        libxslt.so.2 => /usr/local/lib/libxslt.so.2 (0x80110c000)
        libxml2.so.5 => /usr/local/lib/libxml2.so.5 (0x801243000)
        libz.so.2 => /lib/libz.so.2 (0x801482000)
        libiconv.so.3 => /usr/local/lib/libiconv.so.3 (0x801595000)
        libm.so.3 => /lib/libm.so.3 (0x801788000)
        libkvm.so.2 => /lib/libkvm.so.2 (0x8018a8000)

and plparse executes as expected.  (Note that assumed redundant -lobjc flags where removed by the -make patch on the 2005-06-06 which lead to this breakage.)

I suppose this is the kind of issues that libtool was invented for.  I suppose that -make may have to replicate some of that libtool knowledge.  I'll see what else I can dig up.

David Ayers <ayers>
Group Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by rmottola (Posted a comment)
  • -email is unavailable- added by ayers (Posted a comment)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2014-05-29 rmottola StatusNone Invalid
        Open/ClosedOpen Closed

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code