After my bug report, I was running Laz with it idle... I was on a different desktop using the console. I flipped back to the Lazarus desktop and it immediately dumped leaving more GTK errors in the console. I never even clicked on Lazarus that time, just on the desktop chooser to flip back to it. So it's not just related to dragging components.

Regarding the other crash fix of closing tabs, I've updated Lazarus this week, so I'm not sure it's the same bug you fixed, or that the fix worked, but I'll update again to be sure.

P.S. Tony you need to update your TMPack, the lpk doesn't work,(and lcllinux->lclintf) I removed it and recreated it and all was happy so probably just some of the recent changes to the Packager.

I'm working on that as we speak... adding a new component to it, too. I have just about finished a packaging component that facilitates the creation of self-extracting installers using Lazarus. It will compress multiple files and merge them all into one file, with an executable at the head that can extract them all back out with your own custom interface. Basically I just stream all the files together, compressing any after the first, and then tag a custom file allocation table on the end. Compression routines are internal, so no reliance on outside libraries beyond interface.

Thanks,
Tony

hrmm yeah. This sounds like something I might have caused... I will try and reproduce it. I had noticed that after one of my last set of changes dragging controls every now and again I got an AV, but that seemed to have gone away so I didn't look closer. :/

Andrew

P.S. Tony you need to update your TMPack, the lpk doesn't work,(and lcllinux->lclintf) I removed it and recreated it and all was happy so probably just some of the recent changes to the Packager.

+ From: Tony
+ Sent: donderdag 25 september 2003 6:00

[snip]

+ Then, a new crash happened. Just now I was dragging components around
+ my form and crashed: This isn't really much info, but it's all I got.
+ Lazarus immediately exited when dumping this to console. +
+ This was in the console OUTSIDE of the "lazarus > out.txt" file I was
+ creating.
+
+ Gdk-ERROR **: BadDrawable (invalid Pixmap or Window parameter)
+ serial 4697636 error_code 9 request_code 66 minor_code 0

I've seen bad drawables etc before and they are hard to reproduce and track.

Nowadays all gdk errors are handled and a exception is raised, so you could try to run lazarus within lazarus and try to reproduce it, and look at the callstack.

Another option is to modify gtkobject.inc - procedure GLogFunc In the "if ALogLevel and G_LOG_FLAG_FATAL 0" piece, place "asm INT 3 end;" before the raise.
Then run lazarus in GDB and try to reproduce and do a backtrace.

Marc

oh. this might make sense, if its a general expose error, it could be the changes I made to allow DoubleBuffering in GTK2, since I changed the MSG handling so it is using TPaintStruct a bit, I didn't think I did anything screwy but....

I will play with it anyway, maybe also use some smart gdk error push pop like I do in getting the pixel image, so that these kinds of errors(caused by bad code or not) don't kill lazarus as easily(I hope).

Andrew

Sounds like the bug I fixed last week.

A standard gtk error.
Not much information.
I hope that the added IFDEFs for the gtk2 intf didn't mess something up.

Mattias

Regarding the other two "bugs" I reported, I haven't had the change to do more research yet. I'll get back to that very very soon.

But until then...

I've had periodic crashes with Lazarus IDE in Linux lately.

Sometimes when closing a tab in the source editor, I get a IPF and it dies. I've tried to catch that crash's console output, but haven't yet.

Then, a new crash happened. Just now I was dragging components around my form and crashed: This isn't really much info, but it's all I got. Lazarus immediately exited when dumping this to console.

This was in the console OUTSIDE of the "lazarus > out.txt" file I was creating.

Gdk-ERROR **: BadDrawable (invalid Pixmap or Window parameter) serial 4697636 error_code 9 request_code 66 minor_code 0

Here's the data from within the >out.txt that I created when running Lazarus.

************************************************************ MouseUpOnControl Page3:TPAGE
AddComponent A TRUE
[TCustomFormEditor.CreateComponent] Class='TLABEL' opInsert :TLABEL 4224D464
Parent is 'Page3'
TPascalParserTool.BuildTree B OnlyIntf=TRUE
/home/tony/Projects/installer/mainfrm.pas
TPascalParserTool.BuildTree B OnlyIntf=FALSE
/home/tony/Projects/installer/mainfrm.pas
[TEventsCodeTool.CompleteComponent] A Component="Form1:TForm1 [TEventsCodeTool.CompleteComponent]
CurComponent=Wizardnotebook1:TWIZARDNOTEBOOK
[TEventsCodeTool.CompleteComponent] CurComponent=Button1:TBUTTON [TEventsCodeTool.CompleteComponent] CurComponent=Button2:TBUTTON [TEventsCodeTool.CompleteComponent]
CurComponent=Rootfilestore1:TROOTFILESTORE
[TEventsCodeTool.CompleteComponent] CurComponent=Page1:TPAGE [TEventsCodeTool.CompleteComponent] CurComponent=Page2:TPAGE [TEventsCodeTool.CompleteComponent] CurComponent=Page3:TPAGE [TEventsCodeTool.CompleteComponent] CurComponent=Label1:TLABEL [TEventsCodeTool.CompleteComponent] CurComponent=Memo1:TMEMO [TEventsCodeTool.CompleteComponent] CurComponent=Label2:TLABEL [TEventsCodeTool.CompleteComponent] CurComponent=EditDestPath:TEDIT [TEventsCodeTool.CompleteComponent] CurComponent=BtnChoosePath:TBUTTON [TEventsCodeTool.CompleteComponent] CurComponent=Label3:TLABEL [TEventsCodeTool.CompleteComponent] ADDING variable Label3:TLABEL [TEventsCodeTool.CompleteComponent] invoke class completion [TEventsCodeTool.CompleteComponent] END
NEW COMPONENT ADDED: Form.ComponentCount=13 NewCI.Control.Owner.Name=Form1 [TDesigner.MouseLeftUpOnControl] END
************************************************************ MouseDownOnControl Label3:TLABEL No Shift down, No CTRL down [TDesigner.MouseDownOnControl] END
************************************************************ MouseUpOnControl Label3:TLABEL
[TDesigner.MouseLeftUpOnControl] END
************************************************************ MouseDownOnControl Label3:TLABEL No Shift down, No CTRL down [TDesigner.MouseDownOnControl] END
************************************************************ MouseUpOnControl Label3:TLABEL
[TDesigner.MouseLeftUpOnControl] END
************************************************************ MouseDownOnControl Label3:TLABEL No Shift down, No CTRL down [TDesigner.MouseDownOnControl] END
************************************************************ MouseUpOnControl Label3:TLABEL
[TDesigner.MouseLeftUpOnControl] END
************************************************************ MouseDownOnControl Label3:TLABEL No Shift down, No CTRL down [TDesigner.MouseDownOnControl] END

Hmm.. I think this effectively bypasses the logging and exception generation I'd implemented in gtkobject.inc.

The way it was implemented one didn't need extra push and pop code. OK if you hit a bad drawable or so the application exits, but at least one could look at the callstack before it happens.

If it is only for the ability of a backtrace and/or an Exception, I vote for the way it was.

Marc

I don't. This isn't just about the logging, this is about the everything dies and there is no autosave no gracefull exits it just dies out from under you. I want a way to keep going at least long enough to save everything whenever possible, this isn't possible from the interface the way it was in most places, and this is the reason there were already push/pops in a few other locations prior to this where it was aespecially likely to happen.

When some problem happens after working on something for 20 minutes and not having saved then what? oops all data out the window because gdk burped a bad window? If I am wrong fine, revert, but I don't see anyway of handling them safely otherwise.

Andrew

OK what I have done.

I couldn't reprocduce or find what this might be, but I went ahead anyway and made the whole gtk interface trap gdk errors around calls to gdk functions that use windows(and I think I got a bit carried away in a few points and put it around colormap and visual stuff) I may have missed some but overall anything that is possible to cause bad drawable errors from the interface directly should be caught.

When {$DEFINE REPORT_GDK_ERRORS} is enabled in gtkproc.pp (for now I just did it by default) then a gdb cacheable AV error is raised, so using gdb backtrace we can find what routine it actually happens in.

So Tony, if you want to update and try and build lazarus with -g -gl in the compiler options, then run it in gdb, I _think_ it should catch it when it happens again and allow you to get a reasonable bt, and still allow you to continue without losing data.

Andrew

I see your point, but the way it was would be a catch all, so individual handling isn't needed.
The idea behind this was that in this catch all the interface raises an exception no matter what fatal gdk error happened, the IDE handles it and takes proper action like ask to save (or of that isn't possible, save to recoveryfiles). It isn't the case now, but it can. After this exeption is handled, it is over and the application exits.

When some problem happens after working on something for 20 minutes and not having saved then what? oops all data out the window because gdk burped a bad window? If I am wrong fine, revert, but I don't see anyway of handling them safely otherwise.

I might be wrong here, I'll recheck. And I'll also look how usable gdk is at that point (after the error, but before exit). If we can't do anything like showing dialogs or saving files or so, we need the push and pops. Otherwise I think I'll place them between IFDEFs for a while (or so).

Marc