Re: [lmi] Segfault in wxGrid

[Greg Chicares]

On 2016-06-21 23:21, Vadim Zeitlin wrote:
> On Tue, 21 Jun 2016 20:08:19 +0000 Greg Chicares <address@hidden> wrote:

[...backtrace much more useful in an archived year-old build...]

> GC> BTW, that version gives a deeper trace of the call stack (below), which
> GC> makes me wonder whether we've removed some useful debugging option.
> 
>  I think this was a side effect of compiler upgrade, quoting
> https://gcc.gnu.org/onlinedocs/gcc-4.9.1/gcc/Optimize-Options.html
> 
> -fomit-frame-pointer
> 
>       ...
> 
>       Starting with GCC version 4.6, the default setting (when not
>       optimizing for size) for 32-bit GNU/Linux x86 and 32-bit Darwin x86
>       targets has been changed to -fomit-frame-pointer. The default can
>       be reverted to -fno-omit-frame-pointer by configuring GCC with the
>       --enable-frame-pointer configure option.
> 
>       Enabled at levels -O, -O2, -O3, -Os. 
> 
> Without the frame pointer (EBP) and without any extra auxiliary information
> (such as saved in the special FPO section of debug information files by
> Microsoft tools) it becomes impossible to reconstruct the stack, in
> general, and I'm afraid this is what might happen here.

Confirmed. Rebuilding with commit 50b1e9d154014e2f75881cfcce0c4b097dfd0337
to restore '-fno-omit-frame-pointer' gives us the deeper stack trace that
we want.

For the record:

(1) The default was changed "for 32-bit GNU/Linux x86 and 32-bit Darwin x86"
according to the gcc documentation cited above: i.e., not for msw. That
page also says:

| -O also turns on -fomit-frame-pointer on machines where doing so
| does not interfere with debugging.

But apparently MinGW-w64's 32-bit toolchains are configured with
'-momit-leaf-frame-pointer', even though that certainly does seem to
"interfere with debugging".

(2) Omitting the frame pointer gains no benefit for lmi according to
the following measurements:

BEFORE commit 50b1e9d154014e2f75881cfcce0c4b097dfd0337:
/lmi/src/lmi[0]$time make $coefficiency system_test >../log 2>&1
make $coefficiency system_test > ../log 2>&1  86.17s user 210.14s system 176% 
cpu 2:47.91 total
/lmi/src/lmi[0]$time make $coefficiency system_test >../log 2>&1
make $coefficiency system_test > ../log 2>&1  86.84s user 206.33s system 179% 
cpu 2:42.91 total
/lmi/src/lmi[0]$time make $coefficiency system_test >../log 2>&1
make $coefficiency system_test > ../log 2>&1  86.38s user 212.24s system 179% 
cpu 2:46.75 total

HEAD, WITH '-fno-omit-frame-pointer':
/lmi/src/lmi[0]$time make $coefficiency system_test >../log 2>&1
make $coefficiency system_test > ../log 2>&1  86.62s user 208.04s system 178% 
cpu 2:44.64 total
/lmi/src/lmi[0]$time make $coefficiency system_test >../log 2>&1
make $coefficiency system_test > ../log 2>&1  86.60s user 204.94s system 179% 
cpu 2:42.83 total
/lmi/src/lmi[0]$time make $coefficiency system_test >../log 2>&1
make $coefficiency system_test > ../log 2>&1  86.69s user 211.03s system 180% 
cpu 2:44.72 total

(3) Explicitly specifying '-fno-omit-frame-pointer' seems to prevent
'-O2' (e.g.) from omitting the frame pointer. I was surprised to see this.
I took care to put '-O2 -fno-omit-frame-pointer' in that order in the lmi
makefiles, because I thought that would be necessary. They came out in
reverse order when I rebuilt wx with the just-updated 'install_wx.make',
and I didn't think that would give a useful backtrace into wx, but it did.
Perhaps '-fno-omit-frame-pointer' really does override an '-O' option
that comes later on the command line; or maybe '-O' options don't turn on
'-fno-omit-frame-pointer' when '-momit-leaf-frame-pointer' was used to
configure gcc.

(4) '-fno-omit-frame-pointer' shouldn't affect interoperability of
object files, but it's wise to rebuild everything simultaneously:
  /lmi/src/lmi[0]$make $coefficiency --output-sync=recurse -f install_wx.make 
>../log 2>&1
  /lmi/src/lmi[0]$make $coefficiency --output-sync=recurse -f 
install_wxpdfdoc.make >../log 2>&1
  /lmi/src/lmi[0]$make clean
  /lmi/src/lmi[0]$make $coefficiency install check_physical_closure >../log 2>&1

(5) I plan to upgrade wx very soon. Do step (4) above now only if you want
to repeat the demonstration that undoing this undesirable change in the
toolchain restores debuggability at no cost. Once we upgrade wx, we'll
lose this easily-reproducible testcase because the defect it reveals
has been fixed in wx.