[hatari-devel] Re: hatari profiler crash?

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

(I CC'd hatari-devel as this might be of generic interest.)

On maanantai 28 tammikuu 2013, Douglas Little wrote:
> I could subdivide the build options to remove each -fopt from the -O
> switch to maximise visibility of the bug and callstack (given that I'm
> completely unfamiliar with the Hatari code) - perhaps that will give you
> a little more context and a deeper callstack with more values to look
> at?

Thanks, but first I would be interested whether the patch I sent will make
the problem go away (when building with full optimizations), i.e. is
the issue related to changing of the assembly output column offsets.

If Hatari doesn't crash with that patch, you have a working "profile
addresses" command and optimized Hatari binary to speed up DSP emulation.
:-)


> I'll try whether GCC stack protection & mudflap options reveal
> > anything.  Stack overwrites are really nasty and that's really
> > only thing I've found that is useful in finding them.

Seems that it caught at least something in the disassembler code,
but it's in different place.  (I.e. I'm still interested about
whether the previous patch has effect :))


> For the C language, short of inspecting all of the array [] operations
> and pointer dereferences, you probably don't have many easy options for
> finding such bugs...

That's basically what GCC mudflap does:
	http://gcc.gnu.org/wiki/Mudflap_Pointer_Debugging

It slows the binary hugely, but when hunting stack overwrites,
as long as one can still somehow use the program, I don't care. :-)

I have added direct mudflap support to Hatari just for this
reason, it's enabled with CMake ENABLE_MUDFLAP:BOOL=ON variable.
It needs GCC mudflap include & library to build.  I use mudflap
also in breakpoint functionality tests:
http://hg.tuxfamily.org/mercurialroot/hatari/hatari/raw-
file/tip/tests/debugger/makefile


	- Eero

> often though it's just a simple buffer overrun
> close to the crash site and can be found just by inspecting the source
> code.
....
> > I hope soon to have first version of the post-processing script ready.
> 
> Great! :) Look forward to it.