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

 
 

You are not allowed to post comments on this tracker with your current authentification level.

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

Submitted by:  David Ayers <ayers>
Submitted on:  Thu 14 Jul 2005 10:33:13 AM UTC  
 
Category: MakefilesSeverity: 3 - Normal
Item Group: BugStatus: None
Privacy: PublicAssigned to: None
Open/Closed: Open

(Jump to the original submission 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>
Project 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>
Project 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>
Project 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>
Project 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>
Project 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>
Project Member

 

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    No Changes Have Been Made to This Item

    Back to the top


    Powered by Savane 3.1-cleanup