Index:
[thread]
[date]
[subject]
[author]
From: Marcus Sundberg <mackan@stacken.kth.se>
To : ggi-develop@eskimo.com
Date: Mon, 15 Mar 1999 14:16:47 +0100
Re: giiClose() coredump
Dennis Taylor wrote:
>
> So I wrote a really simple test GGI2D program the other night
> to see how GGI2D handles some weird cases in the even-odd
> algorithm. It compiles and runs fine in the X target... but when it
> exits, it coredumps on giiClose() with what looks like a problem in
> X. I figure, given that I know pretty much zero about X programming,
> that I should post it here and see if this will be transparent to
> someone with a higher clue factor. Here's the source code of the
> program (yeah, it's a bit messy, but it's just a test):
>
> #include <stdio.h>
> #include <ggi/ggi.h>
> #include <ggi/ggi2d.h>
>
> #define DEF_X 640
> #define DEF_Y 480
> #define DEF_DEPTH GT_16BIT
>
> ggi2d_coord diamond[ 4 ] = { { 100, 0 },
> { 200, 100 },
> { 100, 200 },
> { 0, 100 }, };
>
> int main( void ) {
> int err;
> ggi_mode mode;
> ggi_visual_t vis;
> ggi_color color;
>
> /* Set up the visual. */
> err = ggiInit();
> if (err)
> ggiPanic( "*** startup panic, can't initialize GGI (err %d)\n", err );
> vis = ggiOpen( NULL );
> if (vis == NULL)
> ggiPanic( "*** startup panic, can't open display\n" );
> if (ggiCheckGraphMode( vis, DEF_X, DEF_Y, DEF_X, DEF_Y, DEF_DEPTH, &mode )) {
> err = ggiSetMode( vis, &mode );
> fputs( "*** using system-suggested graphics mode.\n", stderr );
> ggiFPrintMode( stderr, &mode );
> fputc( '\n', stderr );
> } else {
> err = ggiSetGraphMode( vis, DEF_X, DEF_Y, DEF_X, DEF_Y, DEF_DEPTH );
> }
> if (err)
> ggiPanic( "*** startup panic, can't set graphics mode (err %d)\n", err );
> err = ggi2dInit();
> if (err)
> ggiPanic( "*** startup panic, can't initialize GGI2D (err %d)\n", err );
> err = ggi2dOpen( vis );
> if (err)
> ggiPanic( "*** startup panic, can't open GGI2D visual (err %d)\n", err );
>
> /* Fill the visual with white. */
> color.r = color.g = color.b = 0xFFFF;
> ggiSetGCBackground( vis, ggiMapColor( vis, &color ) );
> ggiSetGCForeground( vis, ggiMapColor( vis, &color ) );
> ggiFillscreen( vis );
>
> /* Draw the polygon in black. */
> ggiSetGCForeground( vis, (ggi_pixel) 0 );
> ggi2dFillPoly( vis, diamond, 4 );
> ggiFlush( vis );
>
> /* Wait for a keypress, then die. */
> ggiGetc( vis );
> ggi2dClose( vis );
> ggiClose( vis );
> ggi2dExit();
> ggiExit();
>
> return( 0 );
> }
>
> It compiles fine with "gcc -Wall -pedantic -g -O -o 2dtest
> 2dtest.c -lggi -lggi2d". Here's the output with GGI_DEBUG=255 on....
>
> (It starts up, draws the screen fine, and then spews a whole lot
> of do_blits while it idles for a couple seconds...)
This is because you don't enter ASYNC mode by calling
ggiSetFlags(vis, GGIFLAG_ASYNC);
right after ggiOpen().
> LibGGI: GGI_X_flush(0x804c480, 0) called
> LibGGI: _ggi_x_do_blit(0x804dce8, 0x0, 640x480) called
> LibGGI: GGI_X_flush(0x804c480, 0) called
> LibGGI: _ggi_x_do_blit(0x804dce8, 0x0, 640x480) called
>
> (Here's where I press any key to kill it.)
>
> LibGII: _giiPollAll(0x804e138, 0xa0, 0xbffffa04) called
> LibGII: GII_xwin_eventpoll(0x804e138) called
> LibGII: GII_xwin_eventpoll: KeyPress
> LibGII: _giiEvQueueAdd(0x804e138, 0xbffff750) called
> LibGII: _giiEvQueueSetup() called
> LibGII: _giiEvQueueSetup alloced 0x806a848
> LibGII: Adding event type 5, size 36 at pos 0
> LibGII: _giiEvQueueRelease(0x804e138, 0xbffffabc, 0xa0) called
> LibGII: queue = 0x804e2b8, queue->queues = 0x804e2bc, queue->queues[queue] = (nil)
> LibGII: queue = 0x804e2b8, queue->queues = 0x804e2bc, queue->queues[queue] = 0x804e6d8
> LibGII: queue = 0x804e2b8, queue->queues = 0x804e2bc, queue->queues[queue] = (nil)
> LibGII: queue = 0x804e2b8, queue->queues = 0x804e2bc, queue->queues[queue] = (nil)
> LibGII: queue = 0x804e2b8, queue->queues = 0x804e2bc, queue->queues[queue] = (nil)
> LibGII: queue = 0x804e2b8, queue->queues = 0x804e2bc, queue->queues[queue] = 0x806a848
> LibGII: _giiEvQueueRelease: Plausible found.
> LibGII: queue = 0x804e2b8, queue->queues = 0x804e2bc, queue->queues[queue] = 0x8066828
> LibGII: queue = 0x804e2b8, queue->queues = 0x804e2bc, queue->queues[queue] = (nil)
> LibGII: queue = 0x804e2b8, queue->queues = 0x804e2bc, queue->queues[queue] = (nil)
> LibGII: queue = 0x804e2b8, queue->queues = 0x804e2bc, queue->queues[queue] = 0x8068838
> LibGII: queue = 0x804e2b8, queue->queues = 0x804e2bc, queue->queues[queue] = (nil)
> LibGII: queue = 0x804e2b8, queue->queues = 0x804e2bc, queue->queues[queue] = (nil)
> LibGII: queue = 0x804e2b8, queue->queues = 0x804e2bc, queue->queues[queue] = (nil)
> LibGII: queue = 0x804e2b8, queue->queues = 0x804e2bc, queue->queues[queue] = (nil)
> LibGII: Retrieved event type 5, size 36.
> LibGGI: ggiExtensionDetach(0x804c480, 0) called
> LibGGI: ggiClose("0x804c480") called
> LibGGI: ggiClose: closing
> LibGGI: _ggiZapDL(0x804c480, 0x804bf24) called
> LibGGI: Disposing "display-x"
> LibGGI: _GGI_mansync_stop() (MANSYNC_CHILD) called.
> LibGGI: _GGI_X_freedbs: XShmDetach(0x804cd60, 58720263)
> LibGGI: X-target closed
> LibGGI: Closing handle: 0x804c848
> LibGGI: _ggiZapDL(0x804c480, 0x804c67c) called
> LibGGI: Disposing "generic-color"
> LibGGI: Closing handle: 0x8050b90
> LibGGI: _ggiZapDL(0x804c480, 0x804c6e4) called
> LibGGI: Disposing "generic-linear-16"
> LibGGI: Closing handle: 0x8050e20
> LibGGI: Disposing "generic-stubs"
> LibGGI: Closing handle: 0x8050930
> LibGGI: _ggiZapDL(0x804c480, 0x804c538) called
> LibGGI: Disposing "generic-stubs-2d"
> LibGGI: Closing handle: 0x8065ce0
> LibGGI: Disposing "helper-mansync"
> LibGGI: Closing handle: 0x804de88
> LibGII: giiClose(0x804e138) called
> LibGII: _giiEvQueueDestroy(0x804e138) called
> LibGII: Desttroying 0x804e2b8, 0x804e2bc
> LibGII: _giiEvQueueDestroy going 0, (nil)
> LibGII: _giiEvQueueDestroy going 1, 0x804e6d8
> LibGII: _giiEvQueueDestroy going 2, (nil)
> LibGII: _giiEvQueueDestroy going 3, (nil)
> LibGII: _giiEvQueueDestroy going 4, (nil)
> LibGII: _giiEvQueueDestroy going 5, 0x806a848
> LibGII: _giiEvQueueDestroy going 6, 0x8066828
> LibGII: _giiEvQueueDestroy going 7, (nil)
> LibGII: _giiEvQueueDestroy going 8, (nil)
> LibGII: _giiEvQueueDestroy going 9, 0x8068838
> LibGII: _giiEvQueueDestroy going 10, (nil)
> LibGII: _giiEvQueueDestroy going 11, (nil)
> LibGII: _giiEvQueueDestroy going 12, (nil)
> LibGII: _giiEvQueueDestroy going 13, (nil)
> LibGII: _giiEvQueueDestroy done
> Segmentation fault (core dumped)
>
> Ouch. So I look at it in gdb, naturally.
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x40004122 in _dl_lookup_symbol (undef_name=0x4010937b "_XimLocalIMFree",
> ref=0xbffffb00, symbol_scope=0x40009fc8, reference_name=0x804c9a0
> "/usr/X11R6/lib/libX11.so.6", flags=2)
> at dl-lookup.c:70
> dl-lookup.c:70: No such file or directory.
> (gdb) bt
> #0 0x40004122 in _dl_lookup_symbol (undef_name=0x4010937b "_XimLocalIMFree",
> ref=0xbffffb00, symbol_scope=0x40009fc8, reference_name=0x804c9a0
> "/usr/X11R6/lib/libX11.so.6", flags=2)
> at dl-lookup.c:70
> #1 0x40005711 in fixup (l=0x804c9d0, reloc_offset=134531536) at
> ../sysdeps/i386/dl-machine.h:252
> #2 0x4000584f in _dl_runtime_resolve () at dl-runtime.c:138
> #3 0x4014191d in XCloseIM ()
> #4 0x401a34c3 in GII_xwin_close (inp=0x804e138) at input.c:386
> #5 0x400c451b in giiClose (inp=0x804e138) at gii.c:723
> #6 0x40017263 in _ggiDestroyVisual (vis=0x804c480) at visual.c:280
> #7 0x40013b91 in ggiClose (visual=0x804c480) at init.c:387
> #8 0x8048b17 in main () at 2dtest.c:60
> (gdb)
>
> This is XF86 3.3.3 on a 2.0.36 Linux kernel, running the March
> 14th snapshot of GGI, which I just compiled tonight. I'm a little
> boggled. Is there anything blatantly wrong about this situation, or is
> this a GII bug, or an X bug, or... what? I'll poke around it more
> tomorrow, but I thought I'd throw it out here in case anyone who knows
> this stuff better could spot the problem.
Could you try commenting out the GGI2D stuff and see if the problem
goes away? GGI2D is officially not in a ready-to-use state, and I'm
not involved in coding it, so I want to know if there's a bug in
there or in any of the other libs. Also, does the LibGGI demos work?
//Marcus
--
-------------------------------+------------------------------------
Marcus Sundberg | http://www.stacken.kth.se/~mackan
Royal Institute of Technology | Phone: +46 707 295404
Stockholm, Sweden | E-Mail: mackan@stacken.kth.se
Index:
[thread]
[date]
[subject]
[author]