Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / lazarus / 2010-11

Debugging Lazarus IDE (Package access violation)

7 messages · 4 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Max Vlasov

Hi,
I encountered several times when Package window fired access violation on different operations. I suppose I should report an issue, but just wondering, is it hard (if it full reproducible) to run another instance of Lazarus and debug it, so the report could contain more information saving the developers' time? Or at least recompile it with an option allowing to show additional information about the error , not only simple "access violation" message?

Thanks

Max Vlasov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20101123/fe819501/attachment.html>

Reply by email

zeljko
to Max Vlasov
Max Vlasov wrote 8 lines
Hi, I encountered several times when Package window fired access violation on different operations. I suppose I should report an issue, but just wondering, is it hard (if it full reproducible) to run another instance of Lazarus and debug it, so the report could contain more information saving the developers' time? Or at least recompile it with an option allowing to show additional information about the error , not only simple "access violation" message?

What widgetset ?

zeljko

Reply by email

Paul Ishenin
to Max Vlasov: I encountered several times when Package window fired access violation on different…

23.11.2010 13:54, Max Vlasov ?????:

I suppose I should report an issue, but just wondering, is it hard (if it full reproducible) to run another instance of Lazarus and debug it, so the report could contain more information saving the developers' time?

Nothing difficult. Open lazarus.lpi in lazarus and press Run. Better to have RTL compiled with debug info.

Best regards,
Paul Ishenin

Reply by email

Max Vlasov
to Paul Ishenin
Paul Ishenin wrote 12 lines
23.11.2010 13:54, Max Vlasov ?????: I suppose I should report an issue, but just > wondering, is it hard (if it full reproducible) to run another instance > of Lazarus and debug it, so the report could contain more information > saving the developers' time? > Nothing difficult. Open lazarus.lpi in lazarus and press Run. Better to have RTL compiled with debug info.

Thanks, Paul

Finally it worked although along the way I managed to solve some problems and set up two instances of Lazarus working at the same comp.

By the way, the bug listed as solved (
http://bugs.freepascal.org/view.php?id=17437) probably still exist. Actually the makefiles in the folder \components\lazcontrols are the only one that occasionally contains extra relative up and after that Lazarus down (../../../Lazarus/lcl instead of ../../lcl), so there's no problem for those who have the root compilation folder named accordingly and the one who has it different (mine was LazComp and nearby older lazarus in Lazarus folder, so I got wrong unit version error since lcl in that folder was older-compiled). Should I just leave a note there or issue a new bug?

Max Vlasov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20101123/ec6280df/attachment.html>

Reply by email

Mattias Gaertner
to Max Vlasov
Show quoted text 24 lines
On Tue, Nov 23, 2010 at 10:26 AM, Paul Ishenin wrote: > 23.11.2010 13:54, Max Vlasov ?????: > > I suppose I should report an issue, but just >> wondering, is it hard (if it full reproducible) to run another instance >> of Lazarus and debug it, so the report could contain more information >> saving the developers' time? >> > > Nothing difficult. Open lazarus.lpi in lazarus and press Run. Better to > have RTL compiled with debug info. > > Thanks, Paul Finally it worked although along the way I managed to solve some problems and set up two instances of Lazarus working at the same comp. By the way, the bug listed as solved ( http://bugs.freepascal.org/view.php?id=17437) probably still exist. Actually the makefiles in the folder \components\lazcontrols are the only one that occasionally contains extra relative up and after that Lazarus down (../../../Lazarus/lcl instead of ../../lcl),

That probably means you are mixing packages from two Lazarus source directories.
This is allowed, although in case of lazcontrols this is almost always a bad idea. I'm not sure where to put a warning for this case.

Show quoted text 5 lines
so there's no problem for those who have the root compilation folder named accordingly and the one who has it different (mine was LazComp and nearby older lazarus in Lazarus folder, so I got wrong unit version error since lcl in that folder was older-compiled). Should I just leave a note there or issue a new bug?

Mattias

Reply by email

Max Vlasov
to Mattias Gaertner

On Tue, Nov 23, 2010 at 3:12 PM, Mattias Gaertner <

Show quoted text 15 lines
wrote: > By the way, the bug listed as solved ( > http://bugs.freepascal.org/view.php?id=17437) probably still exist. Actually > the makefiles in the folder \components\lazcontrols are the only one that > occasionally contains extra relative up and after that Lazarus down > (../../../Lazarus/lcl instead of ../../lcl), That probably means you are mixing packages from two Lazarus source directories. This is allowed, although in case of lazcontrols this is almost always a bad idea. I'm not sure where to put a warning for this case.

Mattias, you were right, I was too fast at the statement of the bug existence, and it seems that there a reason why this makefiles were changed. Initially I opened lazarus.lpi with lazarus 9.28.2, he showed an error in dividerbevel.pas about overriding non-existent method, after that I saw that it's not a good idea trying to compile new lazarus with an old one and went fpc make way, but it looks like this makefiles were automatically managed by the lazarus, that corrected the pathes, right? So the changes I made in the IDE made this mix possible. I just tried to reproduce it from start and yes, the files are changed right after pressing F9 in the old IDE.

The only thing that makes me sad is that there were no save buttons pressed and nevertheless an irreversible change are made to the files (SVN Update no longer download correct versions). I suppose there's no chance for disk-based utilities work other way (for example changing makefile it memory), but can this automatic management be controlled by me in some way?

Max Vlasov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20101123/6feee540/attachment.html>

Reply by email

Mattias Gaertner
to Max Vlasov
Show quoted text 18 lines
On Tue, Nov 23, 2010 at 3:12 PM, Mattias Gaertner < > wrote: > > By the way, the bug listed as solved ( > > http://bugs.freepascal.org/view.php?id=17437) probably still exist. > Actually > > the makefiles in the folder \components\lazcontrols are the only one that > > occasionally contains extra relative up and after that Lazarus down > > (../../../Lazarus/lcl instead of ../../lcl), > > That probably means you are mixing packages from two Lazarus > source directories. > This is allowed, although in case of lazcontrols this is almost always > a bad idea. I'm not sure where to put a warning for this case. > > Mattias, you were right, I was too fast at the statement of the bug existence, and it seems that there a reason why this makefiles were changed.

The package lazcontrols had auto create makefile enabled. I disabled it.

Show quoted text 13 lines
Initially I opened lazarus.lpi with lazarus 9.28.2, he showed an error in dividerbevel.pas about overriding non-existent method, after that I saw that it's not a good idea trying to compile new lazarus with an old one and went fpc make way, but it looks like this makefiles were automatically managed by the lazarus, that corrected the pathes, right? So the changes I made in the IDE made this mix possible. I just tried to reproduce it from start and yes, the files are changed right after pressing F9 in the old IDE. The only thing that makes me sad is that there were no save buttons pressed and nevertheless an irreversible change are made to the files (SVN Update no longer download correct versions). I suppose there's no chance for disk-based utilities work other way (for example changing makefile it memory), but can this automatic management be controlled by me in some way?

It's a compiler option of each package. By default it is disabled.

Mattias

Reply by email