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]
