| All Forums |
Register |
Login |
Search |
Subscriptions |
My Profile |
Inbox |
| Tool Warehouse |
FAQs |
Resources |
Help |
Member List |
Address Book |
Logout |
|
|
RE: clamd STREAM segfault
|
Logged in as: Guest |
| Users viewing this topic: none |
|
Login  |
|
|
 RE: clamd STREAM segfault - Jul. 25, '05, 5:20:40 PM
|
|
|
breiter
Posts: 346
Joined: Jun. 14, '04,
From: Washington, DC
Status: offline
|
Well, I did discover a way to get gethostbyname_r() to work as advertised. It kepy segving until I declared a struct hostent and passed it in by address, rather than declaring a hostent pointer and passing that in.
...
struct hostent *he;
struct cfgstruct *cpt;
...
#ifdef __INTERIX
if((cpt = cfgopt(copt, "TCPAddr"))->enabled) {
int err;
struct hostent h_ent;
do{
err=0;
char c_buff[4096];
gethostbyname_r(cpt->strarg, &h_ent, c_buff, sizeof(c_buff), &err);
}while (err==TRY_AGAIN || err==EINVAL);
if (err) {
logg("!gethostbyname_r(%s) error: %s\n", err);
return -1;
}
he = &h_ent;
server.sin_addr = *(struct in_addr *) he->h_addr_list[0] ;
} else
server.sin_addr.s_addr = INADDR_ANY;
#else
So this code now works, in that it doesn't segv right away and returns a host_ent with valid data. I put a similar block into tcpserver.c which is what sets up the socket listener for the main thread before the threadpool is even created.
The net result is that I now get the exact same behavior as with gethostbyname(). That is everything works until the threadpool is idle for 30 seconds. When a worker thread that has made a call into gethostbyname_r() is deallocated, it segvs out inside of hesiod.c (or so claims gdb). I don't think the copy of source code I have matches up to the build of bind because gdb says it is segv on the function signature declaration hesiod_to_bind(). I don't see how it could actually crash there. My thought is that it actually crashes in the hesiod_end function while tyring to close and free the hessiod_p context pointer.
In any case, the back trace is.
(gdb) frame 0
#0 0x00496f5e in hesiod_end (context=0x11a4120) at hesiod.c:174
/dev/fs/C/Profiles/breiter/Documents/Interix/src/bind-9.2.0/lib/bind/irs/hesiod.c:174:3882:beg:0x496f5e
(gdb) frame 1
#1 0x00488d61 in dns_close (this=0x11b666c) at dns.c:149
/dev/fs/C/Profiles/breiter/Documents/Interix/src/bind-9.2.0/lib/bind/irs/dns.c:149:3580:beg:0x488d61
(gdb) frame 2
#2 0x0047ad83 in gen_close (this=0x11b65e8) at gen.c:245
/dev/fs/C/Profiles/breiter/Documents/Interix/src/bind-9.2.0/lib/bind/irs/gen.c:245:6255:beg:0x47ad83
(gdb) frame 3
#3 0x004765e2 in __net_data_destroy (p=0x11b552c) at irs_data.c:110
/dev/fs/C/Profiles/breiter/Documents/Interix/src/bind-9.2.0/lib/bind/irs/irs_data.c:110:2671:beg:0x4765e2
(gdb) frame 4
#4 0x77ebb49f in ?? () at /tmp/cczLMK6t.s:33
Current language: auto; currently asm
Is it possible that bind is dereferencing a null pointer? Any ideas?
< Message edited by breiter -- Jul. 25, '05, 5:37:07 PM >
|
|
|
|
|
RE: clamd STREAM segfault - Jul. 25, '05, 5:42:04 PM
|
|
|
Rodney
Posts: 3714
Joined: Jul. 9, '02,
From: /Tools lab
Status: offline
|
> The net result is that I now get the exact same behavior as with gethostbyname().
Interesting, but I don't know what to really make of it.
> I don't think the copy of source code I have matches up to the build of bind because gdb
The only change was where I added an extra lock, but that's in a different file entirely.
> My thought is that it actually crashes in the hesiod_end function while tyring to close and free the hessiod_p context pointer.
I'll go look at it to see what I can see.
|
|
|
|
|
RE: clamd STREAM segfault - Jul. 25, '05, 6:46:18 PM
|
|
|
breiter
Posts: 346
Joined: Jun. 14, '04,
From: Washington, DC
Status: offline
|
Incidentally, there is a new stable version 0.86.2 which includes an integer overflow fix in libclamav. I don't want to put a new package out there whith this segv defect, though.
|
|
|
|
|
RE: clamd STREAM segfault - Nov. 23, '05, 7:16:56 AM
|
|
|
breiter
Posts: 346
Joined: Jun. 14, '04,
From: Washington, DC
Status: offline
|
Hah! There is nothing wroing with the clamav nor BIND code: pthreads in libc are the culprit.
http://support.microsoft.com/kb/902074 [October 18, 2005]
"SYMPTOMS
When you run a POSIX Thread (pthread) based application that uses the va_list variable, the computer may slow down, and the application may stop responding on a computer that is running Microsoft Windows Services for UNIX 3.5. Additionally, the application handle count may continuously increase. When this problem occurs, you receive an event ID 2019 error message in Event Viewer."
This hotfix to replace the pthreads implementation in libc fixes the segfault! Which means that the problem isn't quite as inocuous as is implied by the KB article.
|
|
|
|
|
RE: clamd STREAM segfault - Nov. 23, '05, 8:00:15 AM
|
|
|
breiter
Posts: 346
Joined: Jun. 14, '04,
From: Washington, DC
Status: offline
|
Argh! Unfortunately, I spoke too soon. clamd still segfaults eventually.
The solution sill appears to be a "don't do that". Don't use the TCPAddr option in clamd.conf to control access to clamd. Use some form of OS network stack protection like the Windows Firewall or IPSec filtering instead.
< Message edited by breiter -- Nov. 23, '05, 8:02:59 AM >
|
|
|
|
 New Messages |
 No New Messages |
 Hot Topic w/ New Messages |
 Hot Topic w/o New Messages |
|
 Locked w/ New Messages |
 Locked w/o New Messages |
|
 Post New Thread
Reply to Message
Post New Poll
Submit Vote
Delete My Own Post
Delete My Own Thread
Rate Posts |
|
|
|
Printable Version
