core dump from static_table example

[Jochen Katz]

Hi,

> I'm running FreeBsd with the latest agent++/snmp++ and I was tring to
> do some testing, so I tried using the static_table example in the
> agent++ dir.  If I start up the agent and immediately start walking
> either the system group or the snmp group, after about 4 or 5 walks
> (using scotty) I get a segmentation fault.

same here on FreeBsd, but it doesn't matter when the first request is
issued. Multiple snmpwalks can be done _one after the other_ without
problems, but as soon as two snmpwalks are started at the same time, the
agent crashes. So a temporary fix would be to disable threads.

>  I stopped catching the
> signal so it would give me a core and the backtrace says:
> 
> (gdb) bt
> #0  0x280c71fc in RequestList::receive (this=0x806b780, sec=120)
>     at request.cpp:1195
> #1  0x804fc1b in main (argc=2, argv=0xbfbff854) at agent.cpp:444
> #2  0x80496f1 in _start ()

I get the same when issuing multiple requests during agent startup. And
I get the following if multiple requests are sent after the startup of
the agent (lines included, as I modified mib.cpp):

#0  0x8065851 in Mib::process_request (this=0x8143680, req=0x8175c00,
reqind=0)
    at mib.cpp:3110
#1  0x80670a2 in Mib::do_process_request (this=0x8143680, req=0x8175c00)
    at mib.cpp:3277
#2  0x806b11a in mib_method_routine_caller (ptr=0x815e5d0) at
mib.cpp:3813
#3  0x2815fab7 in _thread_start () from /usr/lib/libc_r.so.4
#4  0x0 in ?? ()
(gdb) l
3105                    req->set_oid(tmpoid, reqind);
3106                    entry->start_synch();
3107                    unlock_mib();
3108                    entry->get_next_request(req, reqind);
3109                    entry->end_synch();
3110                    break;
3111            }
3112            }
3113            return TRUE;
3114    }

>  Is there a known solution for this?

Yes:
http://www.google.de/search?hl=de&safe=off&q=pthread+freebsd+fault&meta=
has a link to http://216.70.178.182/freebsd/msg07205.html which states:

| >       are there any known problems with -pthread in 5.0-CURRENT
right
| > now?  anything I can do to debug it (a gdb trace of the core file
shows
| > zip) ...
|
| Yeah, threaded C++ apps that make use of libstdc++ are borken in
| both -current and -stable.  See the stable mailing list and search
| for C++ and/or mozilla.  You can probably get around the problem
| by explicitly linking with -lgcc_r.

So I used 

g++ -g -Wall -o agent agent.o -L../../../lib -L../../../../snmp++/lib
 -L../../../../libdes -lgcc_r -lagent++ -lsnmp++ -ldes -lc_r

to build the agent and get no segmentation faults any longer.

Best regards,
  Jochen