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]