Re: toolchain/50939: Bug in GCC optionization causing i386 net-snmpd to crash

[David Holland <dholland-pbugs%netbsd.org@localhost>]

The following reply was made to PR pkg/50939; it has been noted by GNATS.

From: David Holland <dholland-pbugs%netbsd.org@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: toolchain/50939: Bug in GCC optionization causing i386 net-snmpd
 to crash
Date: Fri, 30 Sep 2016 06:41:16 +0000

 On Fri, Mar 11, 2016 at 02:20:01PM +0000, kivinen%iki.fi@localhost 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
 conclusive.
 
 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
 dholland%netbsd.org@localhost