combining the two replies.
Carl R. Friend wrote: > > I'm still on 2.95.3, backed out all the hacking I did on the > idoutils and rebuilt everything (making subtle changes here and > there to get compiles to run) from scratch. The symptoms are > now identical to what I first saw when I started in on idoutils. when i did setup a solaris vm i do remember taking the gcc from sunfreeware which was at least 3.4.6 https://wiki.icinga.org/display/howtos/Setting+up+a+Solaris+VM never tried the older 2.x.y Carl R. Friend wrote: > > I've got libdbi version 0.8.4 and drivers 0.8.3. The > configuration went smoothly, but produced a Makefile that > contained an (errant, to the compiler I was using) option > of "-std=gnu99" and a questionable optimisation one of "-O20". > I had to manually hack the "-std=gnu99" out of the makefiles > to even get a compile. hmmmmm and compile did not complain/warn about anything (missing)? i'd expect libdbi to have some more dependencies as well. > > > Program received signal SIGSEGV, Segmentation fault. > 0xff032114 in strlen () from /lib/libc.so.1 > (gdb) bt > #0 0xff032114 in strlen () from /lib/libc.so.1 > #1 0xff0693dc in strdup () from /lib/libc.so.1 > #2 0xff34a738 in _dbd_result_add_field () from /usr/local/lib/libdbi.so.1 > #3 0xfefc28c4 in _get_field_info () from /usr/local/lib/dbd/libdbdmysql.so > #4 0xfefc302c in dbd_query () from /usr/local/lib/dbd/libdbdmysql.so > #5 0xff345028 in dbi_conn_query () from /usr/local/lib/libdbi.so.1 reaching this region, you are within libdbi. that will be rather hard to debug then. did you verify it to be run and compiled on your architecture? maybe there's some info on the mailinglists. > > #6 0x3122c in ido2db_db_query (idi=0xffbff6d0, > buf=0x61c58 "SELECT object_id, objecttype_id, name1, name2 FROM > icinga_objects WHERE instance_id=2") at db.c:2612 interesting, now instance_id=2 which would not lead into a db error then. > > #7 0x1963c in ido2db_get_cached_object_ids (idi=0xffbff6d0) at > dbhandlers.c:514 > #8 0x307f0 in ido2db_db_hello (idi=0xffbff6d0) at db.c:1819 db_hello is calling the initial connect to the db, but then loading all cached objects id (not to select on every insert/update being done). > > #9 0x172a0 in ido2db_handle_client_input (idi=0xffbff6d0, buf=0x57a48 > "STARTDATADUMP") at ido2db.c:1569 > #10 0x1705c in ido2db_check_for_client_input (idi=0xffbff6d0) at ido2db.c:1477 > #11 0x16dd8 in ido2db_handle_client_connection (sd=10) at ido2db.c:1354 > #12 0x16c1c in ido2db_wait_for_connections () at ido2db.c:1156 > #13 0x15194 in main (argc=0, argv=0xffbffab4) at ido2db.c:303 > (gdb) given the flow, i suspect that libdbd for myself is kind of broken. or it passes a NULL char ptr to strdup/strlen which leads to a segfault. but to verify you would to use the debug symbols exported on the libdbi + driver and debug that in deep as well. i am not entirely sure what happens in there. > >> ndo2db uses plain mysql-client api, ido2db abstracts that layer to >> libdbi. i would expect an error in between. maybe due to an old compiler >> used. > > I'm going to first, go back and double-check the libdbi and > drivers for sanity and if that fails, try another compiler. > I'll report the results once they're in. Film, as they say, > at eleven. another hint might be the libdbi mailinglists (archive and questions asked). > > > I have very verbose debugging turned on in ido2db.cfg: > > debug_level=-1 > debug_verbosity=2 > debug_file=/usr/local/icinga/var/ido2db.debug > max_debug_file_size=10000000 > debug_readable_timestamp=0 > > Running ido2db in gdb yields the following: > > Program received signal SIGSEGV, Segmentation fault. > 0xff032150 in strlen () from /lib/libc.so.1 > (gdb) bt > #0 0xff032150 in strlen () from /lib/libc.so.1 > #1 0xff09d704 in _ndoprnt () from /lib/libc.so.1 > #2 0xff09fbe0 in vfprintf () from /lib/libc.so.1 > #3 0x2d190 in ido2db_log_debug_info (level=1, verbosity=2, fmt=0x32bf8 > "ido2db_handle_client_input(instance_name=%s) start\n") at logging.c:99 > #4 0x17070 in ido2db_handle_client_input (idi=0xffbff760, buf=0x57340 "") at > ido2db.c:1512 > #5 0x16fc8 in ido2db_check_for_client_input (idi=0xffbff760) at ido2db.c:1476 > #6 0x16dc4 in ido2db_handle_client_connection (sd=10) at ido2db.c:1354 > #7 0x16c1c in ido2db_wait_for_connections () at ido2db.c:1156 > #8 0x15194 in main (argc=0, argv=0xffbffb44) at ido2db.c:303 > (gdb) x/32 0xffbff760 > 0xffbff760: 0x00000000 0x00000000 0x00000000 0x00000000 > 0xffbff770: 0x00000000 0x00000000 0x00000000 0x00000000 > 0xffbff780: 0x00000000 0x00000000 0x00000000 0x00000000 > 0xffbff790: 0x00000000 0x00000000 0x00000000 0x00000000 > 0xffbff7a0: 0x00000000 0x00000000 0x00000000 0x00000000 > 0xffbff7b0: 0x00000000 0x00000000 0x00000000 0x00000000 > 0xffbff7c0: 0x00000000 0x00000000 0x00000000 0x00000000 > 0xffbff7d0: 0x00000000 0x00000000 0x00000000 0x00000000 > (gdb) > > My reading of the above is that the idi structure should be > present at 0xffbff760 but the contents therein are all zero, > including several char pointers including the "instance_name" > which is making the routines in libc crash (and rightly so). ido2db_log_debug_info takes a variable argument list and trusts the caller function to provide non NULL values. the internal call to vfprintf is truly correct. but tbh i have no idea why the provided struct is NULLed. at this stage the client got a connection from idomod, read the first bytes getting the api information, selecting the instance_id via instance_name. i would guess that for some reason the debuglog is called without present information about the instance_name, providing a NULL char ptr and therefore erroring out. probably one of those misses in the code. you might wanna try that diff/commit proposed in https://dev.icinga.org/issues/2271 the current top one over here https://git.icinga.org/?p=icinga-core.git;a=shortlog;h=refs/heads/mfriedrich/ido kind regards, michael -- DI (FH) Michael Friedrich Vienna University Computer Center Universitaetsstrasse 7 A-1010 Vienna, Austria email: [email protected] phone: +43 1 4277 14359 mobile: +43 664 60277 14359 fax: +43 1 4277 14338 web: http://www.univie.ac.at/zid http://www.aco.net Lead Icinga Core Developer http://www.icinga.org ------------------------------------------------------------------------------ RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 _______________________________________________ icinga-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/icinga-users
