On Thu, 27 Nov 2008, Rodrigo Miguel wrote: Hi Rodrigo,
> I think that's not related to harbour, because harbour close the > application gracefully. The issue happens with Gtk itself, when some > invalid pointer is handled or some unknown condition, I couldn't > identify that condition, it just abort the gtk app, so it means that > it exits the gtk main loop, without call the previous GCNotifyClosure > ones. This can be caused by some wrongly passed parameters from Harbour/xhgtk library. I do not know GTK internals well enough to help here but I can give you some advice. 1-st I suggest to clean xhgtk code to eliminate all GTK_ASSERT() warninf messages. In SUSE Linux GTK is compiled with them so they can be easy seen on stderr when you run some application from console window. F.e. gdouble vales seems to not be initialized. In x86 machines it's usually ignored but with some other CPUs and maybe with the newer x86 based one it will not be ignored (validating floating point number costs so it's often removed from CPU/FPU logic) and you will have SIGFPE. The xhgtk was written where there was no support for GC collectible pointer items. Now they exists so it will be good to use them to verify if given item passed from .prg code it's exactly the one which is expected and generate RT error if not. Otherwise user mistake in .prg code can cause that wrong pointer will be passed to internall GTK structures what finally can cause global memory corruption and GTK or HVM crash. In such case it's very hard to locate the real reason because problem can be exploited in different place then was created. To locate it it's necessary to validate whole application code. For me it's enough reason to use GC pointer items always when possible and strict pointer value is necessary. Otherwise most of user will be only able to say that sth crashes. > One case that I've here is related to the gtk_operation_new(). It's > for all signed callbacks to call the function on > g_signal_connect_data(), but specific to this function. I don't know > why, but I'm working with some gtk people to see if is some sort of > gtk bug or not. For sure they know much much better GTK internals and can help much more here. > Thanks anyway, I'm just wondering some way to use a better approach > regarding the gtk callbacks and harbour, instead of rely on > GCNotifyClosure do free up the items allocated by hb_itemNew(). Maybe > create a stack list and then clean up those that weren't freed > properly, etc... It's not a solution but rather workaround to hide the problem. Additionally as long as you will not know what is wrong then with such tricks you can make situation even worse. F.e. it's possible that GTK does not execute destructor because some objects are still accessible. You will not know when you can safely free the object. If you will force it then you can discover some other unpredictable results when sth will activate your callback passing the pointer to memory you freed and it will corrupt sth different. In such case is better to lost some memory then cause unpredictable application crash. Personally I'm finding the GTK API which allows to attach any user pointers and define destructors as very well done and easy to use. The only one problem I see is missing build-in MT protection so it's necessary to serialize GTK calls bu user. The question is why it does not work as expected in your case and what is the real source of problem. Without locating it you will never be sure what is wrong and when it can be exploited again in the future. best regards, Przemek _______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
