View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0026081||Lazarus||Database Components||public||2014-04-27 17:17||2014-05-01 16:06|
|Reporter||Stratis Aravias||Assigned To||Luiz Americo|
|Summary||0026081: TDBEdit connected to a TIntegerField crashes application when a huge number entered manually|
|Description||I have an integer field in mysql 5.5 db where in my tests i tried to enter an invalid value, big enough to see how the application reacts, and instead of a classic exception ... application shuts down with memory leaks...|
In debugger i see that debugger catches the same exception TWICE!
So i tried to make an isolated example to check if it is from my code or not, and i see the almost same results.
Another thing i noticed is that if i try to set with code a huge integer value in the DBEdit box then application fires the exception as expected. But if i try to write it manually the same value (like the end user) then we have the crash situation...
|Steps To Reproduce||You need 1 form with |
1 TSQLConnector for MySQL (i test with 5.5)
1 Db with 1 table with at least 1 INT field
prepare the coffee, and put all the necessary stuff on your form for db connection and try to enter manually an invalid huge integer value in TDBEdit
then light the cigarete and count the catched exceptions from debugger...
|Additional Information||I'll try to send you a small project that may leave you drink the coffee instead of trying to build the example...|
|Tags||crash, DbCtrls, TDBEdit, TFieldDataLink.UpdateData, TIntegerField|
|Fixed in Revision||44867|
bug2.rar (128,798 bytes)
Last edited: 2014-04-27 18:29
1. Please upload zip instead of rar files: http://wiki.lazarus.freepascal.org/How_do_I_create_a_bug_report#Attachments
2. Are you using the x86 or x64 IDE/compiler? It seems you didn't fill in those details.
3. Nice description - does this also work without the cigarette ;)
bug2.zip (131,169 bytes)
1. Sorry, thanks for tip
2. emmmm.... 1 moment plz, ... emmm, don't know! I sit on Windows 7-32 bits, so i supect i use 32 bits (suspect....) .... Where is this ?
3. it depends, if you are not a smoker,i don't know, if you are it is not.
Notice: the example creates a `test` table in the db that you connect (i use MySQL 5.5) but you may change it to another db if you wish...
published.zip (5,385 bytes)
i uploaded an updated version of my demo application that is tested this time (sorry for previous uploads) and shows up my problem. I tried again today to debug it but without any success. Seems that exception is raised in both cases, but somewhere things are not handled correctly... application terminates when user enters an invalid value (and leaving leaks behind)...
P.S. I also tested it with the 1.2.2 (SVN Revision: 44758) and get similar results
Using Lazarus svn 32 bit, windows 7. I get only one exception from TLongintField.SetAsString (Invalid integer) both entering manually and through code. This is the same behavior as Delphi AFAIR. To better handle these errors you can install an exception handler (Application.OnException) and catch EDatabaseError exceptions
The exception is only fired once but when debugging the IDE first show a dialog, if the app is continued the app dialog is show giving the impression of two exceptions
To get the Lazarus version go to Help -> About Lazarus menu
Currently I use the 1.2.2 as i mentioned, downloaded from lazarus site.
Version #: 1.2.2
FPC Version: 2.6.4
SVN Revision: 44758
on windows 7/32 bit.
and work with MySQL 5.5.37
On "set a bad int value" i get the exception as expected and Application
throws the related exception message, which is the expected behaviour (for me).
But on manual entry of a large value i see in debuger the same exception twice
and application terminates WITHOUT showing the related message box, instead it shows a heap dump, which is not expected!
Same behaviour if i run the application direct (not from IDE).
In 2nd case (manual entry) application terminates and shows some pop ups
where states that it has 18 unfreed memory blocks.
I tried also to add the ApplicationProperties component and set an event handler for Application.Exception
procedure TForm1.ApplicationProperties1Exception(Sender: TObject; E: Exception);
and i see that it is reached in debugger but message box is not displayed, instead debuger reports again the exception!!! and then i get the Heap dump pop ups...
Since dbugger catches the exception that means that exception is raised (so is not a matter of TDBEdit's validation) which seems ok, but AFTER that (or before ?) till the final dialog that should display the message something goes wrong. I have also a confirmation from another member in forum for the same behaviour (http://forum.lazarus.freepascal.org/index.php/topic,24397.0.html)
I uploaded also a LOG_FILE while running the project from IDE. I hope it helps.
I traced the code till the
where it reaches the line 724
State := SaveApplicationState;
Result := IDCANCEL;
TaskDialogIndirect(@TaskConfig, @Result, nil, nil);// <<<< here i lost it.
if Result = IDCANCEL then
Result := EscapeResult;
and then i can't follow up, application terminates...
LOG_FILE.zip (24,248 bytes)
||i uploaded a picture where i traced till the point that application tries to update the record again (i think so),|
I could not reproduce with Lazarus 1.3. Someone else with 1.2.2 may test to confirm.
You can also test with a snapshot ftp://wiki.freepascal.org/pub/lazarus/snapshots/ to see if is already tested or related to a system configuration
Anyway there's a easier and better way to get a log: run "lazarus.exe --debug-log=mylogfile.txt"
1.2.2 is released this week, and i tried also tested it also with the released version, so we wait for someone else with 1.2.2 to test this?
Please, also notice the (0074676) where i say that i found another one who confirms the same behaviour.
I'm not doubting that there's a bug. But to fix it we first need to identify.
It may be fixed in trunk or be introduced after 1.2 was branched.
Downloading 1.2.2 now.
||thank you, how can i help on this ?|
as far as i can understand from debuggin (me noob) i see that Application's OnException catches the Exception and calls the messageDlg to show it.
Then i see some win 32 hocus pocus, and then callbacks that calls WMKILLFOCUS on line 208 of dbedit.inc which calls UpdatetData and we have the exception raised again... this seems like an endless loop i think (that is ended with application termination in 2nd attempt)
So from my POV an exception is raised, applicattion is catching it and tries to show the message, which fires a callback in dbedit (which is still in edit mode) that tells it "hey dbedit you are going to loose your focus, what will yo do about it ?" and dbedit responds and tries to update the record again (with the invalid value) which will fire again the same exception, etc etc
Meanwhile the dialog from MessageDlg is not shown, and Application exception handler stills waits for that, and there we get the 2nd exception ...
I hope it helps this...
lol, thats it i think...
I tested it again and this time i DONT PRESS post button while i am inside the TDBEdit control.
Instead i just click on another control (TDBEdit will loose it's focus) and i get the long awaiting message box, with the exception message.
Now if i press post (while i am in another control), i got again the beloved MessageDlg from the exception.
But if you enter the invalid value, and press immediatly the post button without leaving the TDBEdit control then BOOOOM!
So, the problem is on handling the WMKILLFOCUS... who doesn't count that it may be called from windows while they try to show a message dialog with an exception that is raised during updatedata call, and tries to call again the FDatalink.UpdateRecord...
if i comment the line 208 in TDBEdit.WMKillFocus
then dialog box from exception shows up normally...
I don't know what sideffects this may cause in LCL... and it sure has (propably underlying field will not be updated), so comment this is not suggested i think.
So if you enter the invalid value and press TAB, or click in another control then the control will fire the exception and will be shown normally.
But not in the case where you click immediatly on the post button, or the Refresh button from navigator.
What makes the 2 cases so different ???
I managed to reproduce the issue. It's now fixed in trunk and scheduled for the next release. For the time being you can replace TFieldDataLink.UpdateData with the following implementation
if not IsModified then
if Assigned(FOnUpdateData) then
IsModified := False;
||man thank you again, i ll try and test it...|
||seems to solve the problem, thanks again...|
|2014-04-27 17:17||Stratis Aravias||New Issue|
|2014-04-27 17:17||Stratis Aravias||File Added: bug2.rar|
|2014-04-27 17:18||Stratis Aravias||Tag Attached: TIntegerField|
|2014-04-27 17:18||Stratis Aravias||Tag Attached: TDBEdit|
|2014-04-27 17:19||Stratis Aravias||Tag Attached: crash|
||Note Added: 0074620|
||Note Edited: 0074620||View Revisions|
|2014-04-27 18:46||Stratis Aravias||File Added: bug2.zip|
|2014-04-27 18:50||Stratis Aravias||Note Added: 0074622|
|2014-04-27 18:57||Stratis Aravias||Note Edited: 0074622||View Revisions|
|2014-04-29 18:04||Stratis Aravias||File Added: published.zip|
|2014-04-29 18:08||Stratis Aravias||Note Added: 0074668|
|2014-04-29 18:10||Stratis Aravias||Note Edited: 0074668||View Revisions|
|2014-04-29 18:28||Luiz Americo||Note Added: 0074670|
|2014-04-29 20:22||Stratis Aravias||Note Added: 0074673|
|2014-04-29 20:24||Stratis Aravias||Note Edited: 0074673||View Revisions|
|2014-04-29 20:45||Stratis Aravias||Note Added: 0074676|
|2014-04-29 20:48||Stratis Aravias||Note Edited: 0074676||View Revisions|
|2014-04-29 20:59||Stratis Aravias||File Added: LOG_FILE.zip|
|2014-04-29 21:00||Stratis Aravias||Note Edited: 0074676||View Revisions|
|2014-04-29 21:03||Stratis Aravias||Note Edited: 0074676||View Revisions|
|2014-04-29 22:51||Stratis Aravias||File Added: LostInTranslation.png|
|2014-04-29 23:01||Stratis Aravias||Note Added: 0074679|
|2014-04-30 00:49||Luiz Americo||Note Added: 0074680|
|2014-04-30 14:04||Stratis Aravias||Note Added: 0074687|
|2014-05-01 04:00||Luiz Americo||Note Added: 0074702|
|2014-05-01 12:28||Stratis Aravias||Note Added: 0074703|
|2014-05-01 14:40||Stratis Aravias||Note Added: 0074711|
|2014-05-01 14:43||Stratis Aravias||Note Edited: 0074711||View Revisions|
|2014-05-01 14:45||Stratis Aravias||Note Edited: 0074711||View Revisions|
|2014-05-01 14:47||Stratis Aravias||Note Edited: 0074711||View Revisions|
|2014-05-01 14:58||Stratis Aravias||Note Added: 0074717|
|2014-05-01 14:59||Stratis Aravias||Note Edited: 0074717||View Revisions|
|2014-05-01 15:01||Stratis Aravias||Note Edited: 0074717||View Revisions|
|2014-05-01 15:05||Stratis Aravias||Note Added: 0074718|
|2014-05-01 15:06||Stratis Aravias||Note Edited: 0074717||View Revisions|
|2014-05-01 15:08||Stratis Aravias||Note Edited: 0074718||View Revisions|
|2014-05-01 15:28||Stratis Aravias||Note Edited: 0074718||View Revisions|
|2014-05-01 15:29||Stratis Aravias||Note Added: 0074720|
|2014-05-01 15:31||Stratis Aravias||Note Edited: 0074720||View Revisions|
|2014-05-01 15:33||Stratis Aravias||Note Edited: 0074711||View Revisions|
|2014-05-01 15:35||Stratis Aravias||Note Edited: 0074720||View Revisions|
|2014-05-01 15:38||Luiz Americo||Note Added: 0074721|
|2014-05-01 15:38||Luiz Americo||Fixed in Revision||=> 44867|
|2014-05-01 15:38||Luiz Americo||LazTarget||=> -|
|2014-05-01 15:38||Luiz Americo||Status||new => resolved|
|2014-05-01 15:38||Luiz Americo||Resolution||open => fixed|
|2014-05-01 15:38||Luiz Americo||Assigned To||=> Luiz Americo|
|2014-05-01 15:39||Stratis Aravias||Note Edited: 0074720||View Revisions|
|2014-05-01 15:40||Stratis Aravias||Note Added: 0074722|
|2014-05-01 15:50||Stratis Aravias||Note Added: 0074724|
|2014-05-01 16:03||Stratis Aravias||Status||resolved => closed|
|2014-05-01 16:05||Stratis Aravias||Tag Attached: DbCtrls|
|2014-05-01 16:06||Stratis Aravias||Tag Attached: TFieldDataLink.UpdateData|