Re: getpixel/putpixel as function pointers? (Was Re: [Tuxpaint-dev] GDB result)
On Mon, 2005-01-10 at 16:09, Bill Kendrick wrote: > On Mon, Jan 10, 2005 at 03:17:13PM -0500, Albert Cahalan wrote: > > Ensure that FreeType is compiled with -fno-strict-aliasing > > or, slower, with -O0. FreeType violates the C standard, > > which now damn-near prohibits casting pointers. BTW, there > > are violations in the Tux Paint getpixel/putpixel code too. > > Yeah, getpixel/putpixel were pretty much straight out of the example code > for SDL. > > I've been thinking maybe we should use function pointers, so that /every/ > getpixel/putpixel didn't have to say: > > "wait, what BPP am I again?" > > We could even use an array of function pointers, such that: > > getpixel[8] = getpixel8(); > getpixel[16] = getpixel16(); > > etc. > > Then the decision as to which getpixel/putpixel to use could happen > much less often. > > Thoughts? I like it, though it won't fix the C standard violation. Loading a wrong-sized image with a starter uses an unusual bpp value. It isn't converted to the screen bpp before use. If that were fixed, then an array wouldn't be needed. ___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
getpixel/putpixel as function pointers? (Was Re: [Tuxpaint-dev] GDB result)
On Mon, Jan 10, 2005 at 03:17:13PM -0500, Albert Cahalan wrote: > Ensure that FreeType is compiled with -fno-strict-aliasing > or, slower, with -O0. FreeType violates the C standard, > which now damn-near prohibits casting pointers. BTW, there > are violations in the Tux Paint getpixel/putpixel code too. Yeah, getpixel/putpixel were pretty much straight out of the example code for SDL. I've been thinking maybe we should use function pointers, so that /every/ getpixel/putpixel didn't have to say: "wait, what BPP am I again?" We could even use an array of function pointers, such that: getpixel[8] = getpixel8(); getpixel[16] = getpixel16(); etc. Then the decision as to which getpixel/putpixel to use could happen much less often. Thoughts? -bill! [EMAIL PROTECTED] April shower bring Kompressor power! http://newbreedsoftware.com/ ___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] GDB result
On Mon, 2005-01-10 at 14:11, Karl Ove Hufthammer wrote: > OK. I've now run GDB on Tux Paint. Here's the result. It looks like a crash in FreeType, though the stack is too messed up to be sure. Some random ideas: Ensure that FreeType is compiled with -fno-strict-aliasing or, slower, with -O0. FreeType violates the C standard, which now damn-near prohibits casting pointers. BTW, there are violations in the Tux Paint getpixel/putpixel code too. You can binary search throught the code with printf(). Try compiling Tux Paint and/or the libraries with options to do stack checking. ProPolice is used by DragonFly BSD, OpenBSD, and Hardened Gentoo. http://en.wikipedia.org/wiki/StackGuard http://en.wikipedia.org/wiki/ProPolice http://en.wikipedia.org/wiki/Stack-Smashing_Protector http://www.trl.ibm.com/projects/security/ssp/ Using the ProPolice gcc, I think you'd want to compile with these options: -fno-strict-aliasing -fstack-protector-all -fstack-protector -fno-omit-frame-pointer -ggdb ___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
[Tuxpaint-dev] GDB result
OK. I've now run GDB on Tux Paint. Here's the result. GNU gdb 6.3-2mdk (Mandrakelinux) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i586-mandrake-linux-gnu"...Using host libthread_db library "/lib/tls/libthread_db.so.1". (gdb) set args --nostamps --640x480 (gdb) run Starting program: /dokument/cvs-lager/tuxpaint/tuxpaint/tuxpaint --nostamps --640x480 [Thread debugging using libthread_db enabled] [New Thread 1080428256 (LWP 13818)] [New Thread 1089227696 (LWP 13821)] could not open Entries.Extra.Old/rsrc could not open Entries.Old/rsrc could not open fonts.cache-1/rsrc Bad font, 'a' and 'z' match: d05l.pfb, Dingbats, Regular Bad font, 'a' and 'z' match: s05l.pfb, Standard Symbols L, Regular Bad font, 'a' and 'z' match: d05l.pfb, Dingbats, Regular Bad font, 'a' and 'z' match: s05l.pfb, Standard Symbols L, Regular Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1080428256 (LWP 13818)] 0x404a98a7 in ps_hints_apply () from /usr/lib/libfreetype.so.6 (gdb) bt #0 0x404a98a7 in ps_hints_apply () from /usr/lib/libfreetype.so.6 #1 0xbfffdbdc in ?? () #2 0x081a0cc0 in ?? () #3 0x081aa3d8 in ?? () #4 0x4047de1b in ?? () from /usr/lib/libfreetype.so.6 #5 0x081a8638 in ?? () #6 0xbfffdbf4 in ?? () #7 0x404e2ab8 in ?? () from /usr/lib/libfreetype.so.6 #8 0x4047e2fa in FT_Free () from /usr/lib/libfreetype.so.6 #9 0x081a8638 in ?? () #10 0x080a1cd0 in ?? () #11 0x404a9ef6 in ps_hints_apply () from /usr/lib/libfreetype.so.6 #12 0x081aa7c8 in ?? () #13 0x081b2248 in ?? () #14 0xbfffdbd4 in ?? () #15 0x in ?? () #16 0x081a0cf8 in ?? () #17 0x402777c0 in __after_morecore_hook () from /lib/tls/libc.so.6 #18 0x40275ff4 in ?? () from /lib/tls/libc.so.6 #19 0x002d in ?? () #20 0x081a0cb8 in ?? () #21 0x081b2a58 in ?? () #22 0xbfffdc20 in ?? () #23 0xbfffdc3c in ?? () #24 0x081aff64 in ?? () #25 0xbfffdbec in ?? () #26 0x in ?? () #27 0x081a8638 in ?? () #28 0x081aa7c8 in ?? () #29 0x081b2248 in ?? () #30 0xbfffdc14 in ?? () #31 0x in ?? () #32 0x in ?? () #33 0x00024dd3 in ?? () #34 0x01ad in ?? () #35 0x in ?? () #36 0x081a0cc0 in ?? () #37 0x081b2a58 in ?? () ---Type to continue, or q to quit--- #38 0x in ?? () #39 0x081a8678 in ?? () #40 0x in ?? () #41 0x00024dd3 in ?? () #42 0x7d00 in ?? () #43 0x8300 in ?? () #44 0x in ?? () #45 0x in ?? () #46 0x in ?? () #47 0x00024dd3 in ?? () #48 0x in ?? () #49 0x00024dd3 in ?? () #50 0x01ad in ?? () #51 0x in ?? () #52 0x081b2ab8 in ?? () #53 0x0002 in ?? () #54 0x in ?? () #55 0x081abcd8 in ?? () #56 0x0008 in ?? () #57 0x081a9ad8 in ?? () #58 0x0008 in ?? () #59 0xbfffdb90 in ?? () #60 0x in ?? () #61 0x in ?? () #62 0x in ?? () #63 0x in ?? () #64 0x in ?? () #65 0x in ?? () #66 0x in ?? () #67 0x in ?? () #68 0x in ?? () #69 0x in ?? () #70 0x in ?? () #71 0x in ?? () #72 0x in ?? () #73 0x in ?? () #74 0x in ?? () #75 0x in ?? () ---Type to continue, or q to quit--- #76 0x in ?? () #77 0x in ?? () #78 0x in ?? () #79 0x in ?? () #80 0x in ?? () #81 0x in ?? () #82 0x in ?? () #83 0x in ?? () #84 0x in ?? () #85 0x in ?? () #86 0x in ?? () #87 0x in ?? () #88 0x in ?? () #89 0x in ?? () #90 0x in ?? () #91 0x in ?? () #92 0x080ab53c in ?? () #93 0x080a1cd0 in ?? () #94 0xbfffdd80 in ?? () #95 0x404e2ab8 in ?? () from /usr/lib/libfreetype.so.6 #96 0x080ab5a0 in ?? () #97 0x081c8906 in ?? () #98 0xbfffdd80 in ?? () #99 0x404a69ec in FT_Stream_OpenLZW () from /usr/lib/libfreetype.so.6 #100 0x080ab53c in ?? () #101 0x081a9b0c in ?? () #102 0x191afdc8 in ?? () #103 0x in ?? () #104 0x404e1e80 in tt_cmap0_class_rec () from /usr/lib/libfreetype.so.6 #105 0x404caee4 in ah_arctan () from /usr/lib/libfreetype.so.6 #106 0x0101 in ?? () #107 0x404826e7 in FT_Get_Module () from /usr/lib/libfreetype.so.6 #108 0x404dadb2 in sbit_metrics_fields () from /usr/lib/libfreetype.so.6 #109 0x404dadb2 in sbit_metrics_fields () from /usr/lib/libfreetype.so.6 #110 0x080abe50 in ?? () #111 0x40481a5e in ft_service_list_lookup () from /usr/lib/libfreetype.so.6 #112 0x404caee4 in ah_arctan () from /usr/lib/libfreetype.so.6 #113 0x404caee4 in ah_arctan () from /usr/lib/libfreetype.so.6 ---Type to continue, or q to quit--- #114 0x080a1fa8 in ?? () #115 0x404e2ab8 in ?? () from /usr/lib/libfreetype.so.6 #116 0x080a1e4c in ?? () #117 0x080a1e74 in ?? () #118 0
Re: [Tuxpaint-dev] new direct PostScript printing code
On Mon, 2005-01-10 at 13:24, Bill Kendrick wrote: > On Mon, Jan 10, 2005 at 09:14:11AM -0500, Albert Cahalan wrote: > > On Mon, 2005-01-10 at 02:29, Bill Kendrick wrote: > > > I'm curious, did you mean to kill my "#ifdef DEBUG_FONTS" stuff!? :^( > > > > Nope. Sorry. Was that the only thing? > > I can't recall. :^/ I THINK so, though. I just checked. The grey modification was lost as well. I was thinking of switching to a different style of disabled button. You can see it in the screenshots I posted for layout. How do you like that? The lighter grey goes well with it. > When in doubt, run "cvs update" before "cvs commit". > (And/or, if you're subscribed to tuxpaint-commits mailing list, just keep > an eye on it ;^) ) I keep an eye on the web archive, which updates quickly enough. I also run "cvs update"... but my editor doesn't notice. Then I save again, and the "cvs update" gets clobbered. CVS will assume this was intentional. > Either a runtime option, or a "built for debugging" version would be good, > at least for the next release or two, to get any kinks worked-out. > (The feature's great, but ends up relying on the quirkiness of the users' > systems more than any other feature in the past. :^) ) The info isn't just for debugging Tux Paint. It'll also help troubleshoot "why won't this neat new font load" problems. ___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] new direct PostScript printing code
On Mon, Jan 10, 2005 at 09:14:11AM -0500, Albert Cahalan wrote: > On Mon, 2005-01-10 at 02:29, Bill Kendrick wrote: > > I'm curious, did you mean to kill my "#ifdef DEBUG_FONTS" stuff!? :^( > > Nope. Sorry. Was that the only thing? I can't recall. :^/ I THINK so, though. When in doubt, run "cvs update" before "cvs commit". (And/or, if you're subscribed to tuxpaint-commits mailing list, just keep an eye on it ;^) ) > I expect many of those messages to be deleted before the release. > The rest should probably be a run-time option, in case anyone > has trouble. Either a runtime option, or a "built for debugging" version would be good, at least for the next release or two, to get any kinks worked-out. (The feature's great, but ends up relying on the quirkiness of the users' systems more than any other feature in the past. :^) ) -bill! ___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] new direct PostScript printing code
On Mon, 2005-01-10 at 02:29, Bill Kendrick wrote: > I'm curious, did you mean to kill my "#ifdef DEBUG_FONTS" stuff!? :^( Nope. Sorry. Was that the only thing? I expect many of those messages to be deleted before the release. The rest should probably be a run-time option, in case anyone has trouble. ___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
