Peculiar Write Error

[J-G]

On trying to compile [f9]  -  I encountered a "Cannot write to Triangle.lps" which I've not come across before.  There are 3 options I can take  - [Abort], [Retry] or 'close the message' [X].   -   [Retry] returned the same error, [Abort] stopped the compile - both leaving the .lsp file at zero length - and [X] allowed the compile to complete - with the .lps file @ 14k  ???

I do know that such warnings usually indicate that there is not enough space on whichever drive has been assigned, so my next check was to [Save] the project (Ctrl S) and as that was successful I looked at the drive parameters.

The screen shot attached shows that there is close to 7.5Gb available.

Whilst I can proceed, there is obviously something amiss.

I haven't yet closed Lazarus down (I did attempt to do so but the same error came up) so I can't tell whether it's a temporary 'flag' that may be set.

Can anyone suggest what might cause such error ?

[Thaddy]

It can be that there is a version of your program kept running while you try to edit a new version:
While the program is running its sourcecode file is also locked.

[Martin_fr]

Long ago I had a similar issue. The cause was an exception-error in the IDE.

If the code that generates the XML fails with an unexpected exception (E.g. overflow/range-check/nil-deref) then the IDE may report that as write error (its while trying (preparing) to write). That would leave the file empty.

So the question is, what in your session causes this error.


Ideally run your IDE in the debugger. If not get log output with trace.

Either way, first thing you would need is to ensure your IDE is compiled with debug info:
Menu: Tools > Configure build Lazarus
On the dialog, in the input for "Custom options" ensure you have:  -O-1 -gl -gw3
(add at the end, and keep whatever else is in there)
=> re-build the IDE (unless you already had those)

1) Debug:
Run the IDE, open ide/lazarus.lpi => press F9
Then in the 2nd IDE get the error
When the error happen get the stacktrace and other info from the 1st IDE.

2) Open IDE with --debug-log=somefile.txt
get the error, attach the log

[Martin_fr]

If that is really Lazarus 2.2 (Or earlier) as in your signature, then you may have the same error I had / and which is fixed: try to delete all watches and all breakpoints, then see if it works without error.

[J-G]

If that is really Lazarus 2.2 (Or earlier) as in your signature, then you may have the same error I had / and which is fixed: try to delete all watches and all breakpoints, then see if it works without error.

That seems to be the solution @Martin_fr  -  2 watches and ~8 breakpoints  all deleted and the error vanished - many thanks (yet again!   )

@Thaddy  -  only one 'session' in use but I do understand that that could also be a cause.

[Martin_fr]

I don't recall much about the issue (and can't find it in the log...)... There was some overflow, either of them would save some value as part of their setup that would overflow (i.e the code used a 32 bit field for a 64 bit value, or did an addition with overflow). Possible something in int2str or str2int (which I don't recall if it would fail even without range checks...) => Something of those sorts. Long ago.

[Martin_fr]

If you had address breakpoints (in asm window), then maybe baa12a8519c3169dbe111a72d54f13f87b8f7879 

[J-G]

If you had address breakpoints (in asm window), then maybe baa12a8519c3169dbe111a72d54f13f87b8f7879

??  wooosh !  -  way above my head 

   You do keep mistaking me for someone who has some idea about using the tools that Lazarus provides @Martin_fr   

I do use breakpoints, but only in the Editor  ie. 'Click in the left margin of the line to stop at'   --  I've never looked at the asm window with any 'knowledge' and certainly never set a breakpoint in there.

[Martin_fr]

Well, if you didn't use those breakpoints, then it was something else. That was just the one for which I found where it had been fixed.

=> the number can be used at gitlab, to find the commit. But you don't need that, if that wasn't the one that caused your issue / or if you wouldn't apply the patch to your install anyway.

[J-G]

Well, if you didn't use those breakpoints, then it was something else. That was just the one for which I found where it had been fixed.

=> the number can be used at gitlab, to find the commit. But you don't need that, if that wasn't the one that caused your issue / or if you wouldn't apply the patch to your install anyway.

It was obviously something quite obscure. I've been using Laz 2.2.0 since May 2022 and have not previously had any issue.

The 'Woosh' simply meant that seeing a 'number' like that - without context - made little sense  - with your explanation it does!    Since the error has not returned - and the fact that I'm an 'If it aint broke, don't fix it' type  -  I'll leave well alone for now.  There may well come a time when it may be beneficial to update but I haven't seen the need yet.