bugGNUstep - Bugs: bug #24111, NetBSD Unable to detach thread

Group
 
 

bug #24111: NetBSD Unable to detach thread

Submitter:  Riccardo Mottola <rmottola>
Submitted:  Wed 20 Aug 2008 11:19:29 PM UTC
   
 
Category:  Makefiles Severity:  4 - Important
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

Sun 22 Feb 2009 08:31:11 PM UTC, comment #12: 

on netbsd 4.0.1 x86 I get for /usr/lib/libobjc.so

multix lib > nm libobjc.so | grep -i thre
0000f474 T __objc_close_thread_system
0000f468 T __objc_init_thread_system
00015648 B __objc_is_multi_threaded
000155f0 D __objc_runtime_threads_alive
0000f480 T __objc_thread_detach
0000f4a8 T __objc_thread_exit
00015644 B __objc_thread_exit_status
0000f4dc T __objc_thread_get_data
0000f494 T __objc_thread_get_priority
0000f4b4 T __objc_thread_id
0000f4c0 T __objc_thread_set_data
0000f488 T __objc_thread_set_priority
0000f4a0 T __objc_thread_yield
0001564c B _objc_became_multi_threaded
00009d04 T objc_set_thread_callback
0000a044 T objc_thread_add
0000a21c T objc_thread_detach
0000a184 T objc_thread_exit
0000a148 T objc_thread_get_data
0000a1e0 T objc_thread_get_priority
00009d94 T objc_thread_id
0000a008 T objc_thread_remove
0000a164 T objc_thread_set_data
0000a1fc T objc_thread_set_priority
0000a1c4 T objc_thread_yield

so I suppose it is not linked against pthread and netbsd supplies a worse runtime than previous evrsion. The strange part is that it is correclty built with threads enabled, so maybe it is a gcc bug. Let's hope in the next version. It also means that packagers need to package libobjc as well. It should do no harm on previous netbsd evrsions I suppose, our libobjc should always work...

Riccardo Mottola <rmottola>
Group Member
Thu 19 Feb 2009 03:22:42 PM UTC, comment #11: 

doh, on OpenBSD, everything seems to be fine.
The thread problem only seems to happen, when I have gobjc from gcc-4.2 installed. This only has the following symbols:

nm /usr/local/lib/libobjc.so.2.0 | grep thre
0000ee44 T __objc_close_thread_system
0000ee38 T __objc_init_thread_system
20006ab8 B __objc_is_multi_threaded
20002770 D __objc_runtime_threads_alive
0000ee50 T __objc_thread_detach
0000ed68 t __objc_thread_detach_function
0000ee78 T __objc_thread_exit
20006ab4 B __objc_thread_exit_status
0000eeac T __objc_thread_get_data
0000ee64 T __objc_thread_get_priority
0000ee84 T __objc_thread_id
0000ee90 T __objc_thread_set_data
0000ee58 T __objc_thread_set_priority
0000ee70 T __objc_thread_yield
20006abc B _objc_became_multi_threaded
0000e7a0 T objc_set_thread_callback
0000eae0 T objc_thread_add
0000ecb8 T objc_thread_detach
0000ec20 T objc_thread_exit
0000ebe4 T objc_thread_get_data
0000ec7c T objc_thread_get_priority
0000e830 T objc_thread_id
0000eaa4 T objc_thread_remove
0000ec00 T objc_thread_set_data
0000ec98 T objc_thread_set_priority
0000ec60 T objc_thread_yield
20006ac0 b thread_local_storage

obviously, my problem that I reported here:
https://savannah.gnu.org/bugs/?func=detailitem&item_id=25037
I had linked against the wrong libobjc, because I still have this problem reported here:
https://savannah.gnu.org/bugs/?func=detailitem&item_id=25536

So in short, this particular problem doesn't really exist on OpenBSD, sorry for the noise here.

Sebastian Reitenbach <buzzdee>
Group Member
Thu 19 Feb 2009 01:44:24 PM UTC, comment #10: 

Yes, all those undefined pthread_... synbols show that your openbsd system has libobjc linked with a pthread library.
I know the configure script checks for that ... so if it's not working the most likely issue is that your pthread library is missing (or in a location not found by the linker) or has dependencies itsself on another library we are not linking.

Investigating this ought to be fairly easy ... you just try building the little objc test program used by configure, add flags to link the appropriate libraries, and  examine the libraries to find any dependencies they hae, and add those new libraries to the list to be linked.

Once you know the set of libraries used and the order they need to be linked in, you can provide a patch to the gnustep-make configure script so that it will be able to get a working threaded runtime.

Richard Frith-Macdonald <CaS>
Group Member
Thu 19 Feb 2009 01:02:40 PM UTC, comment #9: 

On OpenBSD i seem to have the same problem, usually -lpthread is used.

I checked the system libobjc, a ldd only shows me this:

ldd /usr/lib/libobjc.so.4.0
/usr/lib/libobjc.so.4.0:
        Start    End      Type Open Ref GrpRef Name
        0e4d9000 2e4df000 dlib 1    0   0      /usr/lib/libobjc.so.4.0

but I find pthread related symbols in it:
# nm libobjc.so.4.0  | grep -i thre
000097d8 T __objc_close_thread_system
00009770 T __objc_init_thread_system
2000217c D __objc_is_multi_threaded
200027d4 D __objc_runtime_threads_alive
00009824 T __objc_thread_detach
00004838 t __objc_thread_detach_function
00009894 T __objc_thread_exit
20002178 D __objc_thread_exit_status
00009904 T __objc_thread_get_data
0000986c T __objc_thread_get_priority
000098b4 T __objc_thread_id
000098d0 T __objc_thread_set_data
00009860 T __objc_thread_set_priority
00009878 T __objc_thread_yield
20002180 D _objc_became_multi_threaded
20005bc4 b _objc_thread_attribs
20005bc0 b _objc_thread_storage
00004814 T objc_set_thread_callback
00004dc8 T objc_thread_add
000048ec T objc_thread_detach
000049e0 T objc_thread_exit
00004a5c T objc_thread_get_data
000049a8 T objc_thread_get_priority
00004a20 T objc_thread_id
00004e0c T objc_thread_remove
00004a3c T objc_thread_set_data
00004988 T objc_thread_set_priority
000049c4 T objc_thread_yield
         U pthread_attr_destroy
         U pthread_attr_init
         U pthread_attr_setdetachstate
         U pthread_cond_broadcast
         U pthread_cond_destroy
         U pthread_cond_init
         U pthread_cond_signal
         U pthread_cond_wait
         U pthread_create
         U pthread_exit
         U pthread_getspecific
         U pthread_key_create
         U pthread_key_delete
         U pthread_mutex_destroy
         U pthread_mutex_init
         U pthread_mutex_lock
         U pthread_mutex_trylock
         U pthread_mutex_unlock
         U pthread_self
         U pthread_setspecific

so I guess it should support threading.

Sebastian Reitenbach <buzzdee>
Group Member
Thu 19 Feb 2009 10:53:08 AM UTC, comment #8: 

Possibly the standard netbsd gcc4 libobjc just doesn't support threads.  have you checked that?

Richard Frith-Macdonald <CaS>
Group Member
Thu 19 Feb 2009 10:49:00 AM UTC, comment #7: 

using our libobjc solves the problem, yet I'd like to understand why we don't detect/work with the standard netbsd gcc4 libobjc.

Riccardo Mottola <rmottola>
Group Member
Wed 18 Feb 2009 03:17:17 PM UTC, comment #6: 

I removed the whole /usr/GNUstep, just to be sure I did not have some libobjc lying around.

The problme is indeed the failing test, I copied the relevant piece of the log and I do not understand why -lpthread fails.
In the other attempts of configure, where other libraries get tested, I clearly see the linking failure.
Furthermore, thhis bxo has the same compiler as one year ago, when it used to work... I do not understand.

I tried installing our libobjc and rerunning base tests and not lpthread gets picked up (did not verifiy yet if this solves also the bug in question). Yet I do wonder if it is really necessary, I hope it is not, or the netbsd packages would need to package and install also libobjc.

Riccardo Mottola <rmottola>
Group Member
Tue 17 Feb 2009 08:12:39 AM UTC, comment #5: 

Maybe I have the same problem on OpenBSD 4.4 i386 as reported in bug #25037.

I did ran the tests from the testsuite, and all tests regarding threads did fail on i386, for the same reason, unable to detach thread.


Sebastian Reitenbach <buzzdee>
Group Member
Tue 17 Feb 2009 06:22:23 AM UTC, comment #4: 

It seems to me that the critical part in the output you quote is:

checking whether objc has thread support... no

I'm pretty sure that's from the gnustep-make configure (and base gets the information from make) to determine the threading in use.

Looking at configure.ac for gnustep-make, it seems that it tries a variety of options of linker flags to get threading working, but it's possible that none of those work on your system (it's also possible that a non-threaded objc library is being picked up even though the gcc version in use was compiled for threading).

You could check to see how many libobjc's you have installed, and eliminate possibilities to make sure there's only one.  You could then examine that libobjc to see what it's linked with and figure out the threading flags needed (or if it really doesn't support threading, replace it with one that does).


Richard Frith-Macdonald <CaS>
Group Member
Mon 16 Feb 2009 10:39:09 PM UTC, comment #3: 

indeed, I get:
checking for custom shared objc library... NONE
checking whether objc has thread support... no
checking whether we should use native ObjC exceptions... not requested by user
checking for the GCC version... version: 4.1

but it is very strange not to have threads?

The gcc options seen in configure are:

Configured with: /usr/src/tools/gcc/../../gnu/dist/gcc4/configure --enable-long-long --disable-multilib --enable-threads --disable-symvers --build=i386-unknown-netbsdelf4.99.3 --host=i386--netbsdelf --target=i386--netbsdelf


the correct flag for netbsd is -lpthread I believe, the test of which is:

configure:5739: gcc -o conftest -g -O2 -x objective-c -I.   -fgnu-runtime -DGNU_RUNTIME   conftest.c -lobjc  -lpthread  >&5
In file included from conftest.c:8:
config_thread.m:7: warning: incomplete implementation of class 'NXConstantString'
config_thread.m:7: warning: method definition for '-length' not found
config_thread.m:7: warning: method definition for '-cString' not found
configure:5742: $? = 0
configure:5748: ./conftest
configure:5751: $? = 255
configure: program exited with status 255
configure: failed program was:

what's wrong? I see only warnings...

Riccardo Mottola <rmottola>
Group Member
Fri 22 Aug 2008 03:04:53 PM UTC, comment #2: 

it is stock netbsd 4.0 with gcc 4.1.2.
It works on my older netbsd 2.0 on sparc.
How can I know how my runtime is configured?
Maybe I should try installing our libobjc and then reconfiguring adn installing base?

Riccardo Mottola <rmottola>
Group Member
Thu 21 Aug 2008 06:28:04 AM UTC, comment #1: 

That's just reporting that  the runtime function objc_thread_detach() returned a failure value (zero) ... so it's probably a gcc/runtime bug rather than a GNUstep one.
Possibly you  are somehow linking with a single threaded version of the runtime though?

Richard Frith-Macdonald <CaS>
Group Member
Wed 20 Aug 2008 11:19:29 PM UTC, original submission:  

On x86-32, Netbsd 4.0 I get the following error when starting up FTP (current CVS version with threads):

(gdomap is up and running as root)

2008-08-21 01:20:40.478 FTP[9696] Problem posting notification: <NSException: 0x85285a8> NAME:NSInternalInconsistencyException REASON:Unable to detach thread (last error Undefined error: 0) INFO:(nil)

the application is non functional and needs to be killed.


Riccardo Mottola <rmottola>
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 buzzdee (Posted a comment)
  • -email is unavailable- added by CaS (Posted a comment)
  • -email is unavailable- added by rmottola (Submitted the item)
  •  

    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 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2009-02-22 rmottola StatusNone Invalid
        Open/ClosedOpen Closed
    2009-02-17 CaS CategoryBase/Foundation Makefiles

    Back to the top

    Powered by Savane 3.13-caa5.
    Corresponding source code