Package: tinysnmp-agent Version: 0.8.4 Severity: grave Justification: renders package unusable
This is the same as #282260, but as that's already archived, I'm opening a new bug. The tinysnmpd daemon still doesn't start on sparc but gives a SIGBUS instead. This is with a recompiled (with -O0, as is the default on sparc) package due to #385881. The stack trace with symbols is the same as in #282260: (gdb) run -l debug /etc/tinysnmp.conf /usr/lib/tinysnmp Starting program: /home/niko/src/tinysnmp-0.8.4+debug/agent/tinysnmpd -l debug /etc/tinysnmp.conf /usr/lib/tinysnmp VERBOSE: log.c:603: Starting to log output. VERBOSE: module.c:185: registered module system VERBOSE: module.c:185: registered module snmp Program received signal SIGBUS, Bus error. 0x00017838 in tree_create (type=VALUE, node=0xef897010) at odb.c:148 148 odb->data.value = node->value; (gdb) bt #0 0x00017838 in tree_create (type=VALUE, node=0xef897010) at odb.c:148 #1 0x00017b38 in tree_add (odb=0x2e414, node=0xef897010) at odb.c:215 #2 0x00017a14 in tree_add_child (odb=0x2e3b4, node=0xef897110) at odb.c:188 #3 0x00017be0 in tree_add (odb=0x2e3b4, node=0xef897110) at odb.c:223 #4 0x00017a14 in tree_add_child (odb=0x2e354, node=0xef897210) at odb.c:188 #5 0x00017be0 in tree_add (odb=0x2e354, node=0xef897210) at odb.c:223 #6 0x00017a14 in tree_add_child (odb=0x2e2f4, node=0xef897310) at odb.c:188 #7 0x00017be0 in tree_add (odb=0x2e2f4, node=0xef897310) at odb.c:223 #8 0x00017a14 in tree_add_child (odb=0x2e294, node=0xef897410) at odb.c:188 #9 0x00017be0 in tree_add (odb=0x2e294, node=0xef897410) at odb.c:223 #10 0x00017a14 in tree_add_child (odb=0x2e234, node=0xef897510) at odb.c:188 #11 0x00017be0 in tree_add (odb=0x2e234, node=0xef897510) at odb.c:223 #12 0x00017a14 in tree_add_child (odb=0x2e1d4, node=0xef897610) at odb.c:188 #13 0x00017be0 in tree_add (odb=0x2e1d4, node=0xef897610) at odb.c:223 #14 0x00017a14 in tree_add_child (odb=0x2e14c, node=0xef897710) at odb.c:188 #15 0x00017be0 in tree_add (odb=0x2e14c, node=0xef897710) at odb.c:223 #16 0x00017a14 in tree_add_child (odb=0x2e0ec, node=0xef897810) at odb.c:188 #17 0x00017be0 in tree_add (odb=0x2e0ec, node=0xef897810) at odb.c:223 #18 0x00017a14 in tree_add_child (odb=0x2e0b4, node=0xef897910) at odb.c:188 #19 0x00017be0 in tree_add (odb=0x2e0b4, node=0xef897910) at odb.c:223 #20 0x00017a14 in tree_add_child (odb=0x2d744, node=0xef897a10) at odb.c:188 #21 0x00017be0 in tree_add (odb=0x2d744, node=0xef897a10) at odb.c:223 #22 0x00017de4 in odb_add (odb=0x2d744, oid=0x2d758, value=0xef897a98) at odb.c:266 #23 0x0001a260 in module_extend (oid=0x1c13c, descr=0x1c158 "The MIB module for SNMP entities") at module-system.c:369 #24 0x000142c8 in module_open (path=0xef897df6 "/usr/lib/tinysnmp") at module.c:247 #25 0x0001a89c in main (argc=5, argv=0xef897cc4) at main.c:184 The problem seems to be data alignment: (gdb) print &(odb->data.value) $1 = (snmp_value_t *) 0x2e45c which is not word-aligned. FWIW, I had some success working around this by replacing the assignment with memmove(). This led to other similar bus errors surfacing from either assignments or memcpy() calls, which I also replaced. I did get tinysnmpd to apparently work this way. I don't think it's the right solution, though, but more like a side effect of memmove() copying the data byte-by-byte or something like that. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing') Architecture: sparc (sparc64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-1-sparc64 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages tinysnmp-agent depends on: Ii libabz0 0.6.3 Miscellaneous useful routines ii libber0 0.4.1 A Basic Encoding Rules (ITU X.690) ii libc6 2.3.6.ds1-4 GNU C Library: Shared libraries ii libdebug0 0.4.2 Memory leak detection system and l ii libevent1 1.1a-1 An asynchronous event notification Versions of packages tinysnmp-agent recommends: pn tinysnmp-module-interfaces <none> (no description available) pn tinysnmp-module-resources <none> (no description available) -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]