Recent

Author Topic: IBX, external SIGSEGV At address 1  (Read 2881 times)

mobilevil

  • Jr. Member
  • **
  • Posts: 69
    • http://www.kachun.com
IBX, external SIGSEGV At address 1
« on: July 05, 2018, 03:51:39 pm »
Hello,
Lazarus 1.8.4 64bit on Windows 10 pro 64bit
IBX SVN revision 238, latest. should be the same as 2.3.0 release.

I found that the application may crash when I close it if it is running lazarus ide. as a standalone EXE it is fine.  I think I first saw this problem after I updated to IBX 2.3.0. I think I was using IBX 2.2.0

Is there any problem with my code? or anyone seeing this kind of problem? it feels like a race condition in transaction shut down code.

the crash happens at this line in FormClose event.
  self.IBDatabase1.DefaultTransaction.Active:=false;

procedure TForm1.FormCreate(Sender: TObject);
begin
  DateTimePicker1.Date:=now;
  DateTimePicker1Change(self);
end; 

procedure TForm1.IBDatabase1AfterConnect(Sender: TObject);
begin
  IBEvents1.RegisterEvents;
end;

procedure TForm1.IBEvents1EventAlert(Sender: TObject; EventName: string;
  EventCount: longint; var CancelAlerts: Boolean);
begin
  DateTimePicker1Change(self);//reload data
end;         

procedure TForm1.DateTimePicker1Change(Sender: TObject);
begin
//simplified, there's a date condition based on a checkbox
  ibquery1.SQL.clear;
  ibquery2.SQL.clear;
  ibquery3.SQL.clear;
  ibquery1.SQL.Add('select something');
  ibquery2.SQL.Add('select something');
  ibquery3.SQL.Add('select something');

  ibquery1.close;
  ibquery1.open;
  ibquery2.close;
  ibquery2.open;
  ibquery3.close;
  ibquery3.open;

end;           
procedure TForm1.FormClose(Sender: TObject; var CloseAction: TCloseAction);
begin
  ibquery1.close;
  ibquery2.close;
  ibquery3.close;
  ibevents1.UnRegisterEvents;
  self.IBDatabase1.DefaultTransaction.Active:=false;//crashing here
  self.IBDatabase1.Close();
end; 

tonyw

  • Sr. Member
  • ****
  • Posts: 319
    • MWA Software
Re: IBX, external SIGSEGV At address 1
« Reply #1 on: July 06, 2018, 02:34:25 pm »
I would suggest removing the line

ibevents1.UnRegisterEvents;

In general, there is no need to explicitly call UnRegisterEvents before you close a database connection, as this is done automatically. Queries are also automatically closed and you can remove those lines as well.

Event handling is also multi-threaded and when you close a transaction you might see an event trigger if it was held back by transaction isolation. This is the kind of circumstance where you might see a race condition  and operating under the IDE will change the dynamics.

It would be interesting to know the exact line of code that the exception fired on.

mobilevil

  • Jr. Member
  • **
  • Posts: 69
    • http://www.kachun.com
Re: IBX, external SIGSEGV At address 1
« Reply #2 on: July 08, 2018, 01:04:06 pm »
oh I have tested just now, even without any closing of db/query/event, the crash still happen when I close the application.

egsuh

  • Hero Member
  • *****
  • Posts: 1273
Re: IBX, external SIGSEGV At address 1
« Reply #3 on: July 20, 2018, 10:35:16 am »
I meed SIGSEGV very frequently. Most of them happen when I access "NOT created" object.
If this is the case, the error should have occurred because transaction object is not defined. Would you check if you have a TSQLTransaction within your program, and it is linked to IBDatabase1?

By the way don't we commit or rollback transactions as following?

SQLTransaction1.StartTransaction;
.....
SQLTransaction1.Commit;  or
SQLTransaction1.Rollback; 


I use transactions only in these ways. Please advise me if active := true/false is better.

mobilevil

  • Jr. Member
  • **
  • Posts: 69
    • http://www.kachun.com
Re: IBX, external SIGSEGV At address 1
« Reply #4 on: August 20, 2018, 10:25:16 pm »
oh sorry I didn't notice your post.
the exception is a minor issue that only happens during program exit and under debugger, so I ignored it for now. I should have rolled back to the previous IBX and test though.

yes I have transaction object assigned, but it's TIBTransaction for me. without it nothing will work.

I think both .active:=true or .open are fine, it's some funny ancient decision made in Delphi 1 U think.

 

TinyPortal © 2005-2018