Hello FPC,
Tuesday, January 3, 2012, 10:01:54 PM, you wrote:
Do you know which kind of code I must look for to isolate the problem
?
SG I'd suggest looking at the constructors containing an 'exit' statement,
SG but I'm not entirely sure.
SG Does restoring removed line 287 of psub.pas remove
04.01.2012 15:58, José Mejuto пишет:
Hello FPC,
Tuesday, January 3, 2012, 10:01:54 PM, you wrote:
Do you know which kind of code I must look for to isolate the problem
?
SG I'd suggest looking at the constructors containing an 'exit' statement,
SG but I'm not entirely sure.
SG Does
On 04 Jan 2012, at 15:12, Sergei Gorelkin wrote:
However, you can as well try the attached simple patch. It prevents
temps referenced from 'finally' blocks from being placed to registers.
While I'm not immediately certain how that would be done in the
easiest way, it would be best if that
Hello FPC,
Wednesday, January 4, 2012, 3:12:55 PM, you wrote:
SG I was hoping otherwise... Actually it is very strange that
SG reverting changes at line 700 (which you
SG mentioned earlier) removes the crash, while reverting line
SG 287 does not, because removing
SG pi_needs_implicit_finally
Hello FPC,
Monday, January 2, 2012, 9:27:50 PM, you wrote:
The solution to optimize the unnecessary finally blocks without
breaking exit behavior is still to
be found.
SG More sophisticated patch applied in r19955. If you can test
SG your project with it, that would be just
SG great.
I had
03.01.2012 23:54, José Mejuto пишет:
Hello FPC,
Monday, January 2, 2012, 9:27:50 PM, you wrote:
The solution to optimize the unnecessary finally blocks without
breaking exit behavior is still to
be found.
SG More sophisticated patch applied in r19955. If you can test
SG your project with
31.12.2011 23:17, José Mejuto пишет:
SG Plain removal of this if..else breaks a couple of tests in
SG the testsuite. But the information you
SG provided gives some pointers to look at. At least, adding a
SG check that constructor without
SG pi_needs_implicit_finally flag doesn't have any
02.01.2012 14:16, Sergei Gorelkin пишет:
31.12.2011 23:17, José Mejuto пишет:
I'll be very happy in test any change you may want to try before
commit to SVN. This kind of problems seems to be very difficult to
catch, so I'll try to not change my codebase while you investigate in
order to be
Hello Jonas,
Wednesday, December 28, 2011, 2:43:16 PM, you wrote:
To me it looks like the code is trying to free some strings or
interfaces but at a point where the manager of automated types has
been disabled so the declaration of a new ansistring reconnects
it. Maybe it is a crazy idea but
Hello Jonas,
Wednesday, December 28, 2011, 2:43:16 PM, you wrote:
JM The most likely problem is memory corruption by your program.
[...]
JM give more accurate diagnostics).
A bit more information:
Environment is win32.
The line that raises the exception is in win32callback.inc 2474:
31.12.2011 16:58, José Mejuto пишет:
Hello Jonas,
Wednesday, December 28, 2011, 2:43:16 PM, you wrote:
JM The most likely problem is memory corruption by your program.
[...]
JM give more accurate diagnostics).
A bit more information:
Environment is win32.
The line that raises the
Hello FPC,
Saturday, December 31, 2011, 3:39:59 PM, you wrote:
SG r19668 affects codegeneration of constructors and custom enumerators, and
fixes
SG http://bugs.freepascal.org/view.php?id=20827
SG The reported location of crash in your case is likely
SG unrelated to the actual location of
Hello FPC,
Saturday, December 31, 2011, 5:07:42 PM, you wrote:
//if (cs_implicit_exceptions in
current_settings.moduleswitches) and
// (is_class(procdef.struct) and
(procdef.proctypeoption=potype_constructor)) then
//
Hello FPC,
I'm now running:
Lazarus 0.9.31 r34428
FPC 2.7.1 i386-win32-win32/win64 r19895
With this setup something strange is happening in a project of mine,
when I close the project a SIGSEGV happends in the win32callback.inc
of LCL without callback stack trace and with all local variables
On 28 Dec 2011, at 14:25, José Mejuto wrote:
To me it looks like the code is trying to free some strings or
interfaces but at a point where the manager of automated types has
been disabled so the declaration of a new ansistring reconnects
it. Maybe it is a crazy idea but is the only one that
15 matches
Mail list logo
