Re: Does gtk have issues with STL?

[Lindley M French <lfrench1 gmu edu>]

For the moment, getting Linux to work seems like more trouble than its worth; so Valgrind is out for now. I'll revisit that option tomorrow, when someone who's used GTK on Linux before will be around.

I've set Visual Studio's debug level to 3, and I'm not getting any warnings that way. On level 4 I get "unreferenced formal parameter" all over the place, and a few others, but nothing that looks important.

Although behavior is still somewhat inconsistent, I have found one thing which seems to cause or remove the problem depending on its inclusion:

gtk_button_set_label(GTK_BUTTON(radiobutton),"Dummy");

radiobutton is, naturally, a GtkRadioButton. This function gets called a number of times, to change the button's label depending on what's being shown in the associated window. (The radio button's purpose is to select which window gets the current input.)

The "Dummy" text isn't what's supposed to go there, but the problem occurs even with it.

The GTK_BUTTON typecast does not produce an error.

Another place where a similar issue appears to hold is:

gtk_list_store_set(store, &last, 0, "Dummy", -1);

Including this causes issues----sometimes it'll say "gsignal.c 650 emmission_pop should not be reached, aborting" (or something like that), sometimes it'll say there's a disparity between the list view and the store. It *is* okay to update the store after it's been attached to the tree view, isn't it? Or do I need to stick a mutex in the view redraw function?

I suspect these are merely symptoms of some other corruption, but I can't seem to find it.

I'm using pthreads with this; nothing complex, and I think I have everything mutex'd, but it did make me wonder: Does GTK use gthreads internally, and is there any issue with using gthreads and pthreads at the same time?

Also: Is it bad to emit a signal while in a signal handler callback? In this case I'd like to make sure a scrollbar value-update takes place every time a bounds-update does.

----- Original Message -----
From: Chris MacGregor <chris bouncingdog com>
Date: Friday, February 8, 2008 3:12 pm
Subject: Re: Does gtk have issues with STL?

> If it's not completely impractical, you might consider debugging 
> on 
> Linux a bit - there you can use Valgrind (probably worth the 
> effort to 
> port it over just for that, if it takes less than several days), 
> and if 
> you're multi-threaded, Helgrind (get the very latest release) as 
> well 
> might help you quite a bit.
> 
> Sounds like you're dealing with race conditions (or could be 
> memory 
> corruption, of course). Valgrind/Helgrind could find your problems.
> 
> On 02/08/2008 11:50 AM, Lindley M French wrote:
> > I'd love to think it's my own source code. However, the 
> randomness of the errors I get (or sometimes, don't get) prevents 
> me from easily tracking them down. Is there some randomization at 
> work inside GTK? I can't see why there would be, but it's the only 
> thing I can think of that would cause the same binary code to 
> produce different behavior on successive runs.
> >
> > And I can't form a test case until I know what triggers the 
> crash, because otherwise I won't know if absence of a crash is 
> evidence that the test is working or not.
> >
> > If I had GTK source code to break on, it would make things 
> easier. However, the distribution I'm using didn't come with 
> source, and my attempts to compile the source releases I've found 
> have so far been unsuccessful. Bloody Windows.
> >
> > ----- Original Message -----
> > From: Murray Cumming <murrayc murrayc com>
> > Date: Friday, February 8, 2008 1:26 pm
> > Subject: Re: Does gtk have issues with STL?
> >
> >   
> >> On Fri, 2008-02-08 at 10:44 -0500, Lindley M French wrote:
> >>     
> >>> The instability I was seeing before might have been due to my 
> >>>       
> >> use of an STL map to maintain my list of available windows. Is 
> >> this a known issue, or should I be looking elsewhere?
> >>     
> >>> I'm suspicious because several of the errors I've gotten 
> >>>       
> >> (they're different each time, even if I don't recompile) have 
> >> related to reference counting errors. Since STL maintains some 
> >> internal state, there might be something going on there.
> >>
> >> No, this doesn't make any sense.
> >>
> >> You have probably made errors in your own source code. You 
> should try
> >> valgrind and/or try to reduce it to a simple test case.
> >>
> >> -- 
> >> murrayc murrayc com
> >> www.murrayc.com
> >> www.openismus.com
> >>     
> >>     
> > _______________________________________________
> > gtk-list mailing list
> > gtk-list gnome org
> > http://mail.gnome.org/mailman/listinfo/gtk-list
> >   
>