NetBSD Problem Report #50939
From firstname.lastname@example.org Fri Mar 11 14:17:49 2016
Received: from mail.netbsd.org (mail.netbsd.org [220.127.116.11])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(Client CN "mail.netbsd.org", Issuer "Postmaster NetBSD.org" (verified OK))
by mollari.NetBSD.org (Postfix) with ESMTPS id CEE9D7ABE5
for <gnats-bugs@gnats.NetBSD.org>; Fri, 11 Mar 2016 14:17:49 +0000 (UTC)
Date: Fri, 11 Mar 2016 14:54:12 +0200 (EET)
Subject: Bug in GCC optionization causing i386 net-snmpd to crash
>Synopsis: snmpd crashes when compiled with gcc -O2
>Arrival-Date: Fri Mar 11 14:20:01 +0000 2016
>Last-Modified: Fri Sep 30 06:45:00 +0000 2016
>Originator: Tero Kivinen
>Release: NetBSD 7.0_STABLE
System: NetBSD seuraava.iki.fi 7.0_STABLE NetBSD 7.0_STABLE (GENERIC) #0: Sat Mar 5 20:05:29 EET 2016 email@example.com:/usr/obj/sys/arch/i386/compile/GENERIC i386
I have maching running net-snmpd and immediately when the
monitoring script connects to the snmpd and tries to read cpu
crashes. If the net-snmpd is compiled without optimizations it
does not crash. This only happens on the i386 architecture, it
does not appear on amd64 architecture.
Before the crash the system will print error message to the
sysctl vm.vm_meter failed (errno 0)
Using gdb to debug the code it seems it starts executing
netsnmp_cpu_arch_load, and does the first few calls nomally,
i.e. the cpu_stats call (line 200) etc, and then does the
mem_mib call (line 218), but before actually storing the
mem_stats output to the cpu->* structure (at line 220) it goes
on and runs the NetBSD specific code reading kern.cp_time
(line 233 forward) and after that is done it jumps back to
check the error status of the mem_mib call (at line 219), thus
printing out error message about the sysctl vm.vm_meter
failing (even when it actually did succeed), and then it tries
to store the data to cpu->* structure (at line 220), but as
cpu variable has been trashed at this point, it has value of
0x77 and this will cause crash.
Install NetBSD 7.0 from CVS on i386 machine. Install
/usr/pkgsrc/net/net-snmp and the net-snmp will crash
immediately when it calls the netsnmp_cpu_arch_load.
I.e. start snmpd
In our system it crashed in less than minute.
<edit all Makefiles, and remove -O2 and -O2 from the CFLAGS>
Responsible-Changed-When: Thu, 29 Sep 2016 21:19:02 +0000
Over to maintainer
From: David Holland <firstname.lastname@example.org>
Subject: Re: toolchain/50939: Bug in GCC optionization causing i386 net-snmpd
Date: Fri, 30 Sep 2016 06:41:16 +0000
On Fri, Mar 11, 2016 at 02:20:01PM +0000, email@example.com wrote:
> Using gdb to debug the code it seems it starts executing
> netsnmp_cpu_arch_load, and does the first few calls nomally,
> i.e. the cpu_stats call (line 200) etc, and then does the
> mem_mib call (line 218), but before actually storing the
> mem_stats output to the cpu->* structure (at line 220) it goes
> on and runs the NetBSD specific code reading kern.cp_time
> (line 233 forward) and after that is done it jumps back to
> check the error status of the mem_mib call (at line 219), thus
> printing out error message about the sysctl vm.vm_meter
> failing (even when it actually did succeed), and then it tries
> to store the data to cpu->* structure (at line 220), but as
> cpu variable has been trashed at this point, it has value of
> 0x77 and this will cause crash.
This sounds like it is overwriting its stack, probably in the mem_mib
call. Then when it returns form the mem_mib call it manages to go to
the wrong place. Can you check in the debugger if this is the case?
What gets trashed if you overwrite the stack can depend heavily on
compiler optimizations, so it's not necessarily a gcc bug.
I don't see anything obviously wrong with the code, but that isn't
Also, is this happening on real i386, or in a 32-bit chroot on an
amd64? Might also be a problem with the compat32 sysctl().
David A. Holland
$NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2014
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.