Hi Christoph, Christoph Heine wrote: > Tried a selfbuild syslogd with debugging symbols and ran gdb on it,
Thanks a lot. > -- snip -- > > Successful select, descriptor count = 1, Activity on: 7 > Message from UNIX socket: #7 > > Program received signal SIGSEGV, Segmentation fault. > main (argc=-268437368, argv=0x2711c) at syslogd.c:1111 > 1111 line[i] = line[i+1] = '\0'; > (gdb) print i > $1 = 1880523436 > (gdb) print line > $2 = "<22>Jun 12 19:40:11 postfix/cleanup[12197]: 4F0B5A769: > message-id=<[EMAIL PROTECTED]>", '\0' <repeats > 916 times> I'd assume there's a bug in the sparc code / glibc / kernel somewhere. The code commands recv to return only up to MAXLINE - 2 bytes. > i = recv(fd, line, MAXLINE - 2, 0); The documentation says: All three routines return the length of the message on successful com- pletion. If a message is too long to fit in the supplied buffer, excess bytes may be discarded depending on the type of socket the mes- sage is received from. Thus, a result of 1880523436 is very much wrong and must not be returned at all. I don't think that the bug is in syslogd. > The conclusion is that recv() returns rubbish, which is bad. > I've added a check for the return value of recv, (see below for the > diff). I hope that you were running an experimental kernel or something and that the problem does not occur anymore, otherwise we're really doomed. > I know that it is not a solution for the real problem (I'll mail the > sparc people about this) but it is workaround for my problem and > maybe someone else has the same problem. But I think you can close the > bug. Ok. Regards, Joey -- Every use of Linux is a proper use of Linux. -- Jon 'maddog' Hall Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]