10:04 a.m.
Hello ...
I am using FC3t1 updated to latest rawhide (shouldn't that have made my
system FC3t2? fedora-release still says t1)
I am not sure how best to explain this because I am very new to the
programming world and tend to get lost easily.
However I have encountered something with the latest glibc update in
rawhide and need to find out if it something broken in glibc.
I have been using a BBS program called Synchronet (does anybody remember
dial up BBSes?)
I compile the source from CVS (http://cvs.synchro.net) and it has worked
flawlessly until I updated to glibc-2.3.3-55 (headers, common, devel)
The program compiles without error (just the usual warnings that have
been there for a while)
However now the program won't run correctly. There are a LOT of errors
regarding:
Got signal (26435072)
Signal has no handler (unexpected)
Throwing the program into endless loops.
To ensure that this wasn't a recent change to this program, I reverted
to an older, known working tarball of the source and the same thing
occurred.
One of the developers mentioned that it may be related pthread and to
look for changes in:
sigemptyset()
sigaddset()
pthread_sigmask()
sigwait()
When I reverted back to glibc-2.3.3-54 (common, header, devel) the
problem went away.
I am hoping that someone here with more knowledge than I can shed some
light on this and whether I need to file a bugzilla against glibc or if
there was an intentional change.
I hope that I explained this well enough and thanks for your time.
Robert Couture
10:28 a.m.
On Fri, Sep 24, 2004 at 11:04:31AM -0400, Robert Couture wrote:
sigemptyset()
sigaddset()
pthread_sigmask()
sigwait()
When I reverted back to glibc-2.3.3-54 (common, header, devel) the
problem went away.
The most important change between -54 and -55 was the set{res,re,e}[ug]id
fix.
These functions must affect the whole process, while previously they
impacted on the current thread only.
Can you see if your app is 1) threaded 2) calls one of these functions?
(you can see it e.g. in LD_DEBUG=all dump).
Another change (related) was that in NPTL SIGRTMIN increased, so if
the application hardcodes signal 33 for something instead of using SIGRTMIN,
the problem might be there.
Jakub
4:05 p.m.
When I reverted back to glibc-2.3.3-54 (common, header, devel) the
> problem went away.
The most important change between -54 and -55 was the set
{res,re,e}[ug]id
fix.
These functions must affect the whole process, while previously they
impacted on the current thread only.
Can you see if your app is 1) threaded 2) calls one of these
functions?
(you can see it e.g. in LD_DEBUG=all dump).
Another change (related) was that in NPTL SIGRTMIN increased, so if
the application hardcodes signal 33 for something instead of using
SIGRTMIN,
the problem might be there.
The developer has code to work around broken threads in glibc and asked
me to compile with a commandline that treats bypasses the workaround.
This fails with:
!seteuid FAILED
Operation not permitted
Would that mean that threads are still broken or is it the code that is
not handling the threads properly? (Would you require a code snippet
for this as well?)
And I still get:
Got signal (24964608)
Signal has no handler (unexpected)
The number within the brackets changes upon each run, but is constant
during each run.
He asked my to post this code snippet that is the signal handling thread
to see if you could catch why unexpected signals are happening:
(Please excuse any poor formatting due to cut and paste operations. <g>)
As always, the code is available at cvs.synchro.net
static void handle_sigs(void) {
int sig;
sigset_t sigs;
char str[1024];
thread_up(NULL,TRUE,TRUE);
if (is_daemon) {
/* Write the standard .pid file if running as a daemon
*/
/* Must be here so signals are sent to the correct
thread
*/
if(pidf!=NULL) {
fprintf(pidf,"%d",getpid());
fclose(pidf);
}
}
/* Set up blocked signals */
sigemptyset(&sigs);
sigaddset(&sigs,SIGINT);
sigaddset(&sigs,SIGQUIT);
sigaddset(&sigs,SIGABRT);
sigaddset(&sigs,SIGTERM);
sigaddset(&sigs,SIGHUP);
sigaddset(&sigs,SIGALRM);
/* sigaddset(&sigs,SIGPIPE); */
pthread_sigmask(SIG_BLOCK,&sigs,NULL);
while(1) {
sigwait(&sigs,&sig); /* wait here until signaled */
sprintf(str," Got signal (%d)",sig);
log_puts(LOG_NOTICE,str);
switch(sig) {
/* QUIT-type signals */
case SIGINT:
case SIGQUIT:
case SIGABRT:
case SIGTERM:
_sighandler_quit(sig);
break;
case SIGHUP: /* rerun */
_sighandler_rerun(sig);
default:
sprintf(str," Signal has no handler
(unexpected)"); log_puts
(LOG_NOTICE,str);
} }
}
This is the signal handling thread... it's the bit that's tossing of the
errors you're getting (post those too).
Thanks for your time Jakub, I imagine that you are busy :)
Rob.
5:53 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I add missing support for the new internal symbol in a couple of places
now. The result will likely be in glibc-2.3.3-60. Please try it out
when it becomes available.
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFBWetN2ijCOnn/RHQRAj57AJ90giBesNk3hqW8zzXzBfC7UJGc0ACfU2AS
duMZ4Xg2qy/h+z5XG69lL/8=
=J1nt
-----END PGP SIGNATURE-----
7174
days inactive
7179
days old
4 comments
3 participants
participants (3)
-
Jakub Jelinek -
Robert Couture -
Ulrich Drepper