On Fri, May 14, 2010 at 05:09:56PM -0400, Jorge Arellano Cid wrote:
On Fri, May 14, 2010 at 04:44:30PM -0400, Matthew Craig wrote:
Thanks for the continued diagnostic suggestions. I have joined the dillo-dev mailing list to make it easier for everyone else. I discovered interesting data-point, by chance. Normally, I run dillo with the command parameter "-g 999x666" to fit my screen more appropriately.
---Type <return> to continue, or q <return> to quit--- Core was generated by `dillo -g 999x666 http://uaddit.com/discussions/showthread.php?t=5931'. Program terminated with signal 6, Aborted. [New process 5489] #0 0x2af949f8 in raise () from /lib/libc.so.6 (gdb) bt #0 0x2af949f8 in raise () from /lib/libc.so.6 #1 0x2af9665c in abort () from /lib/libc.so.6 #2 0x0051facc in __gnu_cxx::__verbose_terminate_handler () #3 0x0051d7c4 in __cxxabiv1::__terminate () #4 0x0051d828 in std::terminate () #5 0x0051d9f8 in __cxa_throw () #6 0x0051de84 in operator new () #7 0x0051def8 in operator new[] () #8 0x004d14a0 in fltk::Image::make_current () #9 0x00499eac in ?? ()
This is interesting: it crashes within an FLTK2 function.
I'm using fltk-2.0.x-r7513 and there we have:
void Image::make_current() { // TODO - make the cr point at the image_surface! }
No new() operator, no nothing!
I think you need to check the Image::make_current() implementation in src/x11/Images.cxx. There is a buffer is allocated depending on the window size - which would explain, why the -g 999x666 is needed to trigger the bug. And there is this buffer size computation at line 1035, that I don't fully understand: n = (ld*h+3)&-4; maybe that doesn't work as expected on MIPS? Matthew, could you add a fprintf like fprintf(stderr, "====> n=%d\n", n); right after line 1035 in src/x11/Image.cxx of your fltk2 copy and recompile fltk2 + dillo and run your test again?