Thread: [Gtk1-win-developers] Progress - decloaked GDK pointers
Brought to you by:
robinrowe
Menu
▾
▴
gtk1-win-developers
|
From: Robin R. <ro...@Mo...> - 2004-03-04 07:09:52
|
Hi. Hadn't found time to touch GTK1 for a couple months. Been busy on other things. My attempt to use GDK2 with GTK1 didn't work out. Am back working on GDK1. That has serious problems with releasing HDC handles with live resources in them, causing random crashes inside Windows. Same problem we've known about since last year. That GDK by design casts objects all over the place defeats debugging. This pointer cloaking had me a bit discouraged. Changed GTK1 this week to have all the by-design GTK pointer cloaking turned off so I can see clearly now what is going on. What that means is that GdkWhatever, GdkWhateverPrivate, and GdkWhateverPrivateWin32 are all the same struct type now. In making that change I discovered one place where an up-cast was converting to a type larger than had been allocated in memory. One bug fixed. Testing with HelloGtk, my new decloaked GDK1 immediately hurled on g_free, which puzzled me a bit. Rewrote the basic g_... glib memory handlers to streamline them, but it still crashed. Then I realized that for Windows apps and dlls there are separate heaps, that you have to keep malloc/free calls symmetric to the caller's address space. In other words, no calling local free on a pointer malloc-ed inside a dll. Inadvertently, a header file macro was doing that. Making all g_... memory functions exported dll functions fixed it. Am encouraged that I seem to be back on the right track and can see what's going on while crawling around in the VC++ debugger and BoundsChecker. Looks like quite a few repairs ahead, but making progress. After the GTK1 HDC bugs are fixed I would like to work on tablet support and a new macro recorder feature. Been wanting to work on both of those a long time. Cheers, Robin ------------------------------------------------------------------- Rob...@Mo... Hollywood, California www.CinePaint.org Open source digital motion picture film software |
|
From: Donald M. <do...@dr...> - 2004-03-17 12:50:06
|
Do you have a patch for these changes/bug-fixes? Donald. > -----Original Message----- > From: gtk...@li... > [mailto:gtk...@li...] On > Behalf Of Robin Rowe > Sent: 04 March 2004 07:03 > To: gtk...@li... > Subject: [Gtk1-win-developers] Progress - decloaked GDK pointers > > Hi. Hadn't found time to touch GTK1 for a couple months. Been > busy on other > things. > > My attempt to use GDK2 with GTK1 didn't work out. Am back > working on GDK1. > That has serious problems with releasing HDC handles with > live resources in > them, causing random crashes inside Windows. Same problem > we've known about > since last year. That GDK by design casts objects all over > the place defeats > debugging. This pointer cloaking had me a bit discouraged. > > Changed GTK1 this week to have all the by-design GTK pointer > cloaking turned > off so I can see clearly now what is going on. What that means is that > GdkWhatever, GdkWhateverPrivate, and GdkWhateverPrivateWin32 > are all the > same struct type now. In making that change I discovered one > place where an > up-cast was converting to a type larger than had been > allocated in memory. > One bug fixed. > > Testing with HelloGtk, my new decloaked GDK1 immediately > hurled on g_free, > which puzzled me a bit. Rewrote the basic g_... glib memory > handlers to > streamline them, but it still crashed. Then I realized that > for Windows apps > and dlls there are separate heaps, that you have to keep > malloc/free calls > symmetric to the caller's address space. In other words, no > calling local > free on a pointer malloc-ed inside a dll. Inadvertently, a > header file macro > was doing that. Making all g_... memory functions exported > dll functions > fixed it. > > Am encouraged that I seem to be back on the right track and > can see what's > going on while crawling around in the VC++ debugger and > BoundsChecker. Looks > like quite a few repairs ahead, but making progress. > > After the GTK1 HDC bugs are fixed I would like to work on > tablet support and > a new macro recorder feature. Been wanting to work on both of > those a long > time. > > Cheers, > > Robin > ------------------------------------------------------------------- > Rob...@Mo... Hollywood, California > www.CinePaint.org Open source digital motion picture film software > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President and CEO of > GenToo technologies. Learn everything from fundamentals to system > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click > _______________________________________________ > Gtk1-win-developers mailing list > Gtk...@li... > https://lists.sourceforge.net/lists/listinfo/gtk1-win-developers > |
|
From: Robin R. <ro...@Mo...> - 2004-03-18 07:36:27
|
Donald, > Do you have a patch for these changes/bug-fixes? It's way too unstable to be useful to anyone I think. Robin ------------------------------------------------------------------- Rob...@Mo... Hollywood, California www.CinePaint.org Open source digital motion picture film software |
|
From: Donald M. <do...@dr...> - 2004-03-18 23:27:22
|
Robin, >>Do you have a patch for these changes/bug-fixes? >> >> > >It's way too unstable to be useful to anyone I think. > > Ok fair enough. I have been trying to get Cinepaint to work with your gtkwin1.4 but am coming across a deadlock problem when running any of the load plug-ings. I see a Bug note in layers_dialog.c which refers to the gifload - but I see the same problem with tiff and jpeg (maybe others, have not got round to trying them yet) WHen the plugin calls gimp_image_new( .... ) which ends up causing a menu change for one of the the windows. Which calls the Win32 API function MoveWindow( ) from the WireMsgHandler thread . The window that this is being called for was created in the WinMain thread - which is sitting waiting for the plugin to return. Hence we end up in Deadlock. I found the following post from gtk-devel but there seems to be little more on this. http://mail.gnome.org/archives/gtk-devel-list/2001-November/msg00235.html As the post says there is a problem with multi-threaded apps. Does the suggestion of having a thread in GTK that is always used to create/change Windows seem like a good option to solve this problem. Donald. |
|
From: Robin R. <ro...@Mo...> - 2004-03-22 06:28:44
|
Donald, > As the post says there is a problem with multi-threaded apps. Good work tracking that down! > Does the > suggestion of having a thread in GTK that is always used to > create/change Windows seem like a good option to solve this problem. Not really. GTK seems to have endless problems. Diverting more effort from CinePaint into GTK is not the answer. I have another idea I'm researching. Robin ------------------------------------------------------------------- Rob...@Mo... Hollywood, California www.CinePaint.org Open source digital motion picture film software ----- Original Message ----- From: "Donald MacVicar" <do...@dr...> To: <gtk...@li...> Sent: Thursday, March 18, 2004 3:27 PM Subject: Re: [Gtk1-win-developers] Progress - decloaked GDK pointers > Robin, > > >>Do you have a patch for these changes/bug-fixes? > >> > >> > > > >It's way too unstable to be useful to anyone I think. > > > > > Ok fair enough. > > I have been trying to get Cinepaint to work with your gtkwin1.4 but am > coming across a deadlock problem when running any of the load > plug-ings. I see a Bug note in layers_dialog.c which refers to the > gifload - but I see the same problem with tiff and jpeg (maybe others, > have not got round to trying them yet) > > WHen the plugin calls gimp_image_new( .... ) which ends up causing a > menu change for one of the the windows. Which calls the Win32 API > function MoveWindow( ) from the WireMsgHandler thread . The window that > this is being called for was created in the WinMain thread - which is > sitting waiting for the plugin to return. Hence we end up in Deadlock. > I found the following post from gtk-devel but there seems to be little > more on this. > > http://mail.gnome.org/archives/gtk-devel-list/2001-November/msg00235.html > > As the post says there is a problem with multi-threaded apps. Does the > suggestion of having a thread in GTK that is always used to > create/change Windows seem like a good option to solve this problem. > > Donald. > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President and CEO of > GenToo technologies. Learn everything from fundamentals to system > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click > _______________________________________________ > Gtk1-win-developers mailing list > Gtk...@li... > https://lists.sourceforge.net/lists/listinfo/gtk1-win-developers > > |
|
From: Henning N. L. <hn...@st...> - 2004-03-22 07:50:15
|
Hi Robin, What backend do you use for gthreads? Best regards, hnl_dk - Henning Nielsen Lund Robin Rowe wrote: > Donald, > >> As the post says there is a problem with multi-threaded apps. > > Good work tracking that down! > >> Does the >> suggestion of having a thread in GTK that is always used to >> create/change Windows seem like a good option to solve this problem. > > Not really. GTK seems to have endless problems. Diverting more effort > from CinePaint into GTK is not the answer. > > I have another idea I'm researching. > > Robin > ------------------------------------------------------------------- > Rob...@Mo... Hollywood, California > www.CinePaint.org Open source digital motion picture film software > > ----- Original Message ----- > From: "Donald MacVicar" <do...@dr...> > To: <gtk...@li...> > Sent: Thursday, March 18, 2004 3:27 PM > Subject: Re: [Gtk1-win-developers] Progress - decloaked GDK pointers > > >> Robin, >> >>>> Do you have a patch for these changes/bug-fixes? >>>> >>>> >>> >>> It's way too unstable to be useful to anyone I think. >>> >>> >> Ok fair enough. >> >> I have been trying to get Cinepaint to work with your gtkwin1.4 but >> am coming across a deadlock problem when running any of the load >> plug-ings. I see a Bug note in layers_dialog.c which refers to the >> gifload - but I see the same problem with tiff and jpeg (maybe >> others, have not got round to trying them yet) >> >> WHen the plugin calls gimp_image_new( .... ) which ends up causing a >> menu change for one of the the windows. Which calls the Win32 API >> function MoveWindow( ) from the WireMsgHandler thread . The window >> that this is being called for was created in the WinMain thread - >> which is sitting waiting for the plugin to return. Hence we end up >> in Deadlock. I found the following post from gtk-devel but there >> seems to be little more on this. >> >> http://mail.gnome.org/archives/gtk-devel-list/2001-November/msg00235.html >> >> As the post says there is a problem with multi-threaded apps. Does >> the suggestion of having a thread in GTK that is always used to >> create/change Windows seem like a good option to solve this problem. >> >> Donald. >> >> >> >> ------------------------------------------------------- >> This SF.Net email is sponsored by: IBM Linux Tutorials >> Free Linux tutorial presented by Daniel Robbins, President and CEO of >> GenToo technologies. Learn everything from fundamentals to system >> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click >> _______________________________________________ >> Gtk1-win-developers mailing list >> Gtk...@li... >> https://lists.sourceforge.net/lists/listinfo/gtk1-win-developers >> >> > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President and CEO of > GenToo technologies. Learn everything from fundamentals to system > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click > _______________________________________________ > Gtk1-win-developers mailing list > Gtk...@li... > https://lists.sourceforge.net/lists/listinfo/gtk1-win-developers |
|
From: Henning N. L. <hn...@st...> - 2004-03-22 09:06:58
|
Henning Nielsen Lund wrote: > Hi Robin, > > What backend do you use for gthreads? as there are different backends for gthreads (Win32) ... there is the Win32-thread backend ... and there is the pthreads backend. For the pthreads backend are there two libraries for win32: http://sources.redhat.com/pthreads-win32/ that has been used by gtk before they made the win32-thread backend. And there is GNU pth ( IIRC has there only been a CygWin port ) - http://www.ossp.org/pkg/lib/pth/ - that has a pthreads emulation. > > Best regards, > hnl_dk - Henning Nielsen Lund > > > Robin Rowe wrote: >> Donald, >> >>> As the post says there is a problem with multi-threaded apps. >> >> Good work tracking that down! >> >>> Does the >>> suggestion of having a thread in GTK that is always used to >>> create/change Windows seem like a good option to solve this >>> problem. >> >> Not really. GTK seems to have endless problems. Diverting more effort >> from CinePaint into GTK is not the answer. >> >> I have another idea I'm researching. >> >> Robin >> ------------------------------------------------------------------- >> Rob...@Mo... Hollywood, California >> www.CinePaint.org Open source digital motion picture film software >> >> ----- Original Message ----- >> From: "Donald MacVicar" <do...@dr...> >> To: <gtk...@li...> >> Sent: Thursday, March 18, 2004 3:27 PM >> Subject: Re: [Gtk1-win-developers] Progress - decloaked GDK pointers >> >> >>> Robin, >>> >>>>> Do you have a patch for these changes/bug-fixes? >>>>> >>>>> >>>> >>>> It's way too unstable to be useful to anyone I think. >>>> >>>> >>> Ok fair enough. >>> >>> I have been trying to get Cinepaint to work with your gtkwin1.4 but >>> am coming across a deadlock problem when running any of the load >>> plug-ings. I see a Bug note in layers_dialog.c which refers to the >>> gifload - but I see the same problem with tiff and jpeg (maybe >>> others, have not got round to trying them yet) >>> >>> WHen the plugin calls gimp_image_new( .... ) which ends up causing a >>> menu change for one of the the windows. Which calls the Win32 API >>> function MoveWindow( ) from the WireMsgHandler thread . The window >>> that this is being called for was created in the WinMain thread - >>> which is sitting waiting for the plugin to return. Hence we end up >>> in Deadlock. I found the following post from gtk-devel but there >>> seems to be little more on this. >>> >>> http://mail.gnome.org/archives/gtk-devel-list/2001-November/msg00235.html >>> >>> As the post says there is a problem with multi-threaded apps. Does >>> the suggestion of having a thread in GTK that is always used to >>> create/change Windows seem like a good option to solve this >>> problem. >>> >>> Donald. >>> >>> >>> >>> ------------------------------------------------------- >>> This SF.Net email is sponsored by: IBM Linux Tutorials >>> Free Linux tutorial presented by Daniel Robbins, President and CEO >>> of GenToo technologies. Learn everything from fundamentals to system >>> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click >>> _______________________________________________ >>> Gtk1-win-developers mailing list >>> Gtk...@li... >>> https://lists.sourceforge.net/lists/listinfo/gtk1-win-developers >>> >>> >> >> >> >> ------------------------------------------------------- >> This SF.Net email is sponsored by: IBM Linux Tutorials >> Free Linux tutorial presented by Daniel Robbins, President and CEO of >> GenToo technologies. Learn everything from fundamentals to system >> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click >> _______________________________________________ >> Gtk1-win-developers mailing list >> Gtk...@li... >> https://lists.sourceforge.net/lists/listinfo/gtk1-win-developers > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President and CEO of > GenToo technologies. Learn everything from fundamentals to system > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click > _______________________________________________ > Gtk1-win-developers mailing list > Gtk...@li... > https://lists.sourceforge.net/lists/listinfo/gtk1-win-developers |
Thanks for helping keep SourceForge clean.
X