From: <Chr...@ar...> - 2003-11-25 16:36:48
|
Hi, I've solved it without having to modify tst_sig at all. The key question in all of this was: "Why the 'signal() failed for signal 34.' doesn't occur on every single Linux with LinuxThreads." I'd followed the bit in the Makefile about uncommenting the lines such that: CROSS_COMPILER=/usr/local/arm/gnu/release/arm-linux/bin/arm-linux- etc. When I tried using the Makefile as supplied, and just do a "make CC=arm-linux-gcc", the tests it built started working. I think this is due to the "LOADLIBES=-lpthread -lc -lresolv -lnss_dns -lnss_files -lm -lc" in the Makefile. If you uncomment this you are changing the link order from the default. Since sigaction is defined in multiple different places within glibc this affects which version of it you pick up. By putting -pthread at the start I was then picking up the linuxthreads version, where as with the default link order I'd get a different sigaction. This is a partial guess at what's been happening, but it seems to explain it all. I expect that the fixes you suggest below will fix the problem I started with. However, other tests that were failing for different reasons are now passing as a result of being built with "make CC=arm-linux-gcc", so I'm sticking with this. There are a number of questions here: - Is this a potential real bug in linux, could multi-threaded actions start attaching handlers to signals that are needed by the threading library - and no one has noticed because every multi-threaded application always links libpthread in first? - As some tests fail for different reasons if I build using the modified Makefile (eg. clone02), what's at fault - glibc/LTP? - Should the LTP Makefile be changed to remove the details about how to override the defaults, since this seems to break a number of tests? I'm happy though, its working now. Chris On 25/11/2003 16:02:23 Robert Williamson wrote: >Okay....how about if I do this: > >/* Ignore all real-time signals */ >case __SIGRTMIN: >case __SIGRTMIN+1: >case __SIGRTMIN+2: >case __SIGRTMIN+3: >case __SIGRTMIN+4: >case __SIGRTMIN+5: >case __SIGRTMIN+6: >case __SIGRTMIN+7: >case __SIGRTMIN+8: >case __SIGRTMIN+9: >case __SIGRTMIN+10: >case __SIGRTMIN+11: >case __SIGRTMIN+12: >case __SIGRTMIN+13: >case __SIGRTMIN+14: >case __SIGRTMIN+15: >case __SIGRTMAX-15: >case __SIGRTMAX-14: >case __SIGRTMAX-13: >case __SIGRTMAX-12: >case __SIGRTMAX-11: >case __SIGRTMAX-10: >case __SIGRTMAX-9: >case __SIGRTMAX-8: >case __SIGRTMAX-7: >case __SIGRTMAX-6: >case __SIGRTMAX-5: >case __SIGRTMAX-4: >case __SIGRTMAX-3: >case __SIGRTMAX-2: >case __SIGRTMAX-1: >case __SIGRTMAX: > >I tried this with NPTL and it works....should work for you as well. > >-Robbie > >(See attached file: tst_sig.c) > >Robert V. Williamson <ro...@us...> >Linux Test Project >IBM Linux Technology Center >Web: http://ltp.sourceforge.net >IRC: #ltp on freenode.irc.net >==================== >"Only two things are infinite, the universe and human stupidity, and I'm >not sure about the former." -Albert Einstein > > > >Chr...@ar... >Sent by: To: Robert Williamson/Austin/IBM@IBMUS >ltp...@li...ur cc: ltp...@li... >ceforge.net Subject: Re: [LTP] signal() failed for signal >34. > > >11/25/2003 06:23 AM > > > > > > >On 24/11/2003 21:10:06 ltp-list-admin wrote: >>I'm not sure if my first reply went out.... >> >>I tried using an #ifdef line, but wanted to know if that works before I >>commit it: >> >>#ifdef __pthread_sig_debug >>case __pthread_sig_debug: >>#endif >> >>Could you try this and let me know? > >No, that didn't work. > >From: >http://www.die.net/doc/linux/man/man7/signal.7.html > >"Linux supports real-time signals as originally defined in the POSIX.4 >real-time extensions (and now included in POSIX 1003.1-2001). Linux >supports 32 real-time signals, numbered from 32 (SIGRTMIN) to 63 >(SIGRTMAX). (Programs should always refer to real-time signals using >notation SIGRTMIN+n, since the range of real-time signal numbers varies >across Unices.) > >Unlike standard signals, real-time signals have no predefined meanings: the >entire set of real-time signals can be used for application-defined >purposes. (Note, however, that the LinuxThreads implementation uses the >first three real-time signals.)" > >So we need something like: > >#ifdef LINUX_THREADS >case SIGRTMIN: >case SIGRTMIN+1: >case SIGRTMIN+2: >#endif > >I'm looking into this but could someone could explain to me why the >"signal() failed for signal 34." doesn't occur on every single Linux with >LinuxThreads, considering the man page extract above? > >Thanks, >Chris > >This e-mail message is intended for the addressee(s) only and may contain >information that is the property of, and/or subject to a confidentiality >agreement between the intended recipient(s), their organisation and/or the >ARM Group of Companies. If you are not an intended recipient of this e-mail >message, you should not read, copy, forward or otherwise distribute or >further disclose the information in it; misuse of the contents of this >e-mail message may violate various laws in your state, country or >jurisdiction. If you have received this e-mail message in error, please >contact the originator of this e-mail message via e-mail and delete all >copies of this message from your computer or network, thank you. > > > > > >------------------------------------------------------- >This SF.net email is sponsored by: SF.net Giveback Program. >Does SourceForge.net help you be more productive? Does it >help you create better code? SHARE THE LOVE, and help us help >YOU! Click Here: http://sourceforge.net/donate/ >_______________________________________________ >Ltp-list mailing list >Ltp...@li... >https://lists.sourceforge.net/lists/listinfo/ltp-list > > - tst_sig.c -- Chris Pedley, Graduate Engineer Intellectual Property Products Division ARM Ltd, 110 Fulbourn Rd, Cambridge CB1 9NJ UK Tel : +44 1223 400847 Fax: +44 1223 400410 This e-mail message is intended for the addressee(s) only and may contain information that is the property of, and/or subject to a confidentiality agreement between the intended recipient(s), their organisation and/or the ARM Group of Companies. If you are not an intended recipient of this e-mail message, you should not read, copy, forward or otherwise distribute or further disclose the information in it; misuse of the contents of this e-mail message may violate various laws in your state, country or jurisdiction. If you have received this e-mail message in error, please contact the originator of this e-mail message via e-mail and delete all copies of this message from your computer or network, thank you. |