Possible bug on TDBEDIT on Mint - Error, SIGSEGV

[incendio]

Hi guys,

I have this code (Lazarus 2.2.2 for  Windows 32bit, IBX 2.5.0.9999, Firebird 3)

Code: Pascal  [Select][+][-]

1. procedure TInpInOtFrm.DtTbl1BeforeEdit(DataSet: TDataSet);
2. begin
3.   if not(DM.Dt1_Ok2Edit(DtTbl1)) then Abort();
4. end;
5.  
6. function TDM.Dt1_Ok2Edit(DtTbl1:TIBDataset) : boolean;
7. begin
8.   if(DataIsLock) and not(DtTbl1.FieldByName('lck_by').IsNull) then Result := false
9.   else Result := true;
10. end;
11.  

Those codes runs perfectly fine on Windows OS.

When compiled on Linux Mint, with Lazarus 2.2.0, same version of IBX, the Abort() method raised an error : SIGSEGV.

But, the same method on different event didn't raised an error.
Here the code with Abort() method but still fine

Code: Pascal  [Select][+][-]

1. procedure TInpInOtFrm.DtTbl1BeforePost(DataSet: TDataSet);
2. begin
3.   if not (DtTbl1TRS_DT.IsNull) then
4.   begin
5.      if not (DM.IsTrsDtValid(DtTbl1TRS_DT.AsDateTime)) then
6.      begin
7.         utils.Error('Not valid date!');
8.         TrsDt.SetFocus();
9.         Abort();
10.      end;
11.   end;
12. end;
13.  
14.  

What's wrong here?

[rvk]

What should Abort do??

https://www.freepascal.org/docs-html/rtl/sysutils/abort.html

It raises an exception.
Did you handle the exception correctly someplace else?

BTW. What is DM?
Is that your instance of TDM.
It might be better then to remove the DM. or use Dataset.Dt1_Ok2Edit.

Abort forces an exception.
Usually that means an operation is halted.
It might not be the best method to do this in a Lazarus application because you don't know where the exception ends up.

[incendio]

What should Abort do??

https://www.freepascal.org/docs-html/rtl/sysutils/abort.html

It raises an exception.
Did you handle the exception correctly someplace else?

BTW. What is DM?
Is that your instance of TDM.
It might be better then to remove the DM. or use Dataset.Dt1_Ok2Edit.

1. Abort -> cancel editing, no handle exception made, should I? On Windows it is OK, also on Linux it's OK, see edited topic on post # 1
2. DM is a name of a datamodule

[rvk]

PS. On the first you do it in beforeEdit.
On the second in beforePost.

They are different .

1. Abort -> do nothing, no handle exception made, should I? On Windows it is OK, also on Linux it's

Abort forces an exception.

Abort raises an EAbort exception

.

So where are you handling the exception?

The exception can be handled differently in beforepost and beforeedit.
It can even be handled differently between OSses.

If you want to abort editing then you could try a Dataset.Cancel.
It'll cancel the edit of the dataset and prevent anything being entered in the TDBEdit.

PS. You could also try to catch the exception at the place where you are calling Dataset.Edit (if you do that manually).

[incendio]

PS. On the first you do it in beforeEdit.
On the second in beforePost.

If you want to abort editing then you could try a Dataset.Cancel.
It'll cancel the edit of the dataset and prevent anything being entered in the TDBEdit.

Tried Dataset.Cancel, only worked once, then didn't work.

When tried to input text 'a' in TDBEdit, it did cancel the input, but input again, will success. BeforeEdit event not triggered again on the second attempt to edit TDBEdit.

[rvk]

What happens if you only do the abort?

Code: Pascal  [Select][+][-]

1. procedure TInpInOtFrm.DtTbl1BeforeEdit(DataSet: TDataSet);
2. begin
3.   // commented out.  if not(DM.Dt1_Ok2Edit(DtTbl1)) then Abort();
4.   Abort();
5. end;

If that's not giving you an SIGSEGV then the problem is in your code (DM.Dt1_Ok2Edit).

[incendio]

What happens if you only do the abort?

Code: Pascal  [Select][+][-]

1. procedure TInpInOtFrm.DtTbl1BeforeEdit(DataSet: TDataSet);
2. begin
3.   // commented out.  if not(DM.Dt1_Ok2Edit(DtTbl1)) then Abort();
4.   Abort();
5. end;

If that's not giving you an SIGSEGV then the problem is in your code (DM.Dt1_Ok2Edit).

Same error : SIGSEGV

[rvk]

What exactly is DtTbl1 for component?

[incendio]

What exactly is DtTbl1 for component?

What do you mean?

It is just TIBDataset with Cache Update enabled, to receive input from users.

[rvk]

Mmm, why is there a TIBDataset on your form while you also have a datamodule?
Normally you have a DM for those components (although I do usually have them on my form because I have multiple instances of the same form).

Anyway... OnBeforeEdit from a dataset should be able to handle exceptions.

BeforeEdit is the triggered at the start of the TDataset.Edit method. The dataset is still in dsBrowse state when this event is triggered. If an exception is raised in the BeforeEdit event handler, then the dataset will remain in dsBrowse state, and the edit operation is cancelled.

https://www.freepascal.org/docs-html/fcl/db/tdataset.beforeedit.html

So it might be a bug.

[incendio]

Mmm, why is there a TIBDataset on your form while you also have a datamodule?
Normally you have a DM for those components (although I do usually have them on my form because I have multiple instances of the same form).

Anyway... OnBeforeEdit from a dataset should be able to handle exceptions.

BeforeEdit is the triggered at the start of the TDataset.Edit method. The dataset is still in dsBrowse state when this event is triggered. If an exception is raised in the BeforeEdit event handler, then the dataset will remain in dsBrowse state, and the edit operation is cancelled.

https://www.freepascal.org/docs-html/fcl/db/tdataset.beforeedit.html

So it might be a bug.

A bug from IBX?

Will try to inform the creator then.

[tonyw]

Mmm, why is there a TIBDataset on your form while you also have a datamodule?
Normally you have a DM for those components (although I do usually have them on my form because I have multiple instances of the same form).

Anyway... OnBeforeEdit from a dataset should be able to handle exceptions.

BeforeEdit is the triggered at the start of the TDataset.Edit method. The dataset is still in dsBrowse state when this event is triggered. If an exception is raised in the BeforeEdit event handler, then the dataset will remain in dsBrowse state, and the edit operation is cancelled.

https://www.freepascal.org/docs-html/fcl/db/tdataset.beforeedit.html

So it might be a bug.

A bug from IBX?

Will try to inform the creator then.

This is not going to be an IBX bug. TIBDataset is a subclass of TDataset (which is in the FCL) and, IBX gets involved only when TDataset.InternalEdit is called. This is called after the BeforeEdit handler runs.

An exception raised in TDataset.Edit flows back to whoever called it. This may be either your code or a Data Aware control (In the LCL) which is where you should look for any dodgy exception handling.

On the other hand. Sysutils.Abort() is a one liner:

 Raise EAbort.Create(SAbortError) at CodePointer(Get_Caller_addr(Get_Frame));

I'm just wondering if the Windows/Linux difference is in the call to CodePointer and is due to the debug level you have compiled at. E.g. if you have not compiled in any debugging info under Linux  then maybe this call will result in a segment fault.

I would replace your call to Abort with your own exception and see if you get the same result.

Also, looking at your code, if seems odd that you are looking at a record field when deciding whether to abort. Remember that IBX has a record cache which is separate for each TIBDataset instance. Setting a field in one TIBDataset instance does not necessarily result in the field value being propagated to all such instances whether in the same process or another process. Firebird transaction control is a much better way to co-ordinate multiple threads working on the same data but, even here, you have to call TDataset.Post to lock a record and update the database. TDataset.Edit is not enough.

[rvk]

It is just TIBDataset with Cache Update enabled, to receive input from users.

What component switches the dataset to .Edit?

TDBGrid? TDBEdit? TDBNavigator? Or something else? Or do you do it manually?
In that case the exception handling is done in that component.

Abort just gives an exception. It shouldn't matter if you do it yourself with Exception.Create or call Abort.
The caller should handle that exception.

[incendio]

This is not going to be an IBX bug. TIBDataset is a subclass of TDataset (which is in the FCL) and, IBX gets involved only when TDataset.InternalEdit is called. This is called after the BeforeEdit handler runs.

An exception raised in TDataset.Edit flows back to whoever called it. This may be either your code or a Data Aware control (In the LCL) which is where you should look for any dodgy exception handling.

On the other hand. Sysutils.Abort() is a one liner:

 Raise EAbort.Create(SAbortError) at CodePointer(Get_Caller_addr(Get_Frame));

I'm just wondering if the Windows/Linux difference is in the call to CodePointer and is due to the debug level you have compiled at. E.g. if you have not compiled in any debugging info under Linux  then maybe this call will result in a segment fault.

I would replace your call to Abort with your own exception and see if you get the same result.

Also, looking at your code, if seems odd that you are looking at a record field when deciding whether to abort. Remember that IBX has a record cache which is separate for each TIBDataset instance. Setting a field in one TIBDataset instance does not necessarily result in the field value being propagated to all such instances whether in the same process or another process. Firebird transaction control is a much better way to co-ordinate multiple threads working on the same data but, even here, you have to call TDataset.Post to lock a record and update the database. TDataset.Edit is not enough.

I don't know much about Lazarus, all I have done is untick Generate debuging info in project option. Do you have any hints what parameters should be set in Linux?

My goal is, if column lck_by is not null, then cancel editing from users. Dataset.Cancel seem able to solved this, unfortunately, event BeforeEdit only triggered once, after a call to Dataset.Cancel, it won't call again, hence I use Abort with is fine in Windows.

How to use IBX's record cache to achieve my goal?

[incendio]

It is just TIBDataset with Cache Update enabled, to receive input from users.

What component switches the dataset to .Edit?

TDBGrid? TDBEdit? TDBNavigator? Or something else? Or do you do it manually?
In that case the exception handling is done in that component.

Abort just gives an exception. It shouldn't matter if you do it yourself with Exception.Create or call Abort.
The caller should handle that exception.

Not sure understand your question.

Here's what happen :
1. Users opened previously saved data.
2. After data displayed to users,  users click TDbEdit and start typing, this will fire up BeforeEdit event.