Free Downloads, Community Forum,
FAQs and Developer Resources


Make /Tools Your Home | Link to us

Today's posts | Posts since last visit | Most Active Topics

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
  Printable Version
All Forums >> [SFU / Interix / SUA Technology] >> Interix Advanced Forum >> RE: clamd STREAM segfault Page: <<   < prev  1 [2]
Login
Message << Older Topic   Newer Topic >>
RE: clamd STREAM segfault - Jul. 24, '05, 11:40:00 AM   
Rodney

 

Posts: 3714
Joined: Jul. 9, '02,
From: /Tools lab
Status: offline
> I don't think that got us anywhere.

Guess not
Back to the thinking board...

(in reply to breiter)
Post #: 21
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 >

(in reply to Rodney)
Post #: 22
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.

(in reply to breiter)
Post #: 23
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.

(in reply to Rodney)
Post #: 24
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.

(in reply to breiter)
Post #: 25
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 >

(in reply to breiter)
Post #: 26
Page:   <<   < prev  1 [2]
All Forums >> [SFU / Interix / SUA Technology] >> Interix Advanced Forum >> RE: clamd STREAM segfault Page: <<   < prev  1 [2]
Jump to:





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


Search All Forums -

Advanced search


SPONSORS



Forum Software © ASPPlayground.NET Advanced Edition 2.5 ANSI

0.063