In my experince sigsegv occurs mostly when a field or variable is accessed before initialization.
Try to set a breakpoint in dongle.initkey call. And evaluate the dongle field (open debugger evaluate window) Look for dongle or one of the tsentinel fields being nil Liiz Em 22/06/2015 05:10, "Bo Berglund" <[email protected]> escreveu: > > On Mon, 22 Jun 2015 09:16:20 +0300, patspiper <[email protected]> > wrote: > > >On 22/06/15 02:00, Bo Berglund wrote: > >> > >> I just made a first test by adding the object to my main form as a > >> private variable. > >Which object? Better show the code. > > Here is the current state of the main form where the object is > handled: > > unit FormMain; > > {$mode objfpc}{$H+} > > interface > > uses > Classes, SysUtils, FileUtil, Forms, Controls, Graphics, Dialogs, > StdCtrls, > ExtCtrls, > Sentinel; > > type > > { TfrmMain } > > TfrmMain = class(TForm) > btnFindKey: TButton; > stxSerialNo: TStaticText; > procedure btnFindKeyClick(Sender: TObject); > procedure FormClose(Sender: TObject; var CloseAction: > TCloseAction); > procedure FormCreate(Sender: TObject); > procedure Timer1Timer(Sender: TObject); > private > { private declarations } > Dongle: TSentinel; <== My private object variable > public > { public declarations } > end; > > var > frmMain: TfrmMain; > > implementation > > {$R *.lfm} > > { TfrmMain } > > > procedure TfrmMain.btnFindKeyClick(Sender: TObject); > var > SerialNo: word; > begin > //Code to check for the dongle and if found display its contents > Dongle.InitKey; <= I get the exception here > Dongle.AppNumber := 1; > if Dongle.CheckKey then > begin > SerialNo := Dongle.SerialNo; > stxSerialNo.Caption := IntToStr(SerialNo); > end; > end; > > procedure TfrmMain.FormClose(Sender: TObject; var CloseAction: > TCloseAction); > begin > Dongle.Free; <= Destroying the object > end; > > procedure TfrmMain.FormCreate(Sender: TObject); > begin > Dongle := TSentinel.Create; <= Creating the object > end; > > end. > > >> "Project DongleTest raised exception class > >> 'External: SIGSEGV'." > >The 1st thing that comes to mind is that spromeps.obj is 32 bit and your > >Lazarus/fpc and Windows are most probably 64 bit. But I am not sure how > >the compiler/linker would react to that. > > I think I create a 32 bit application, see below. > > >You had posted previously: > >Input file: SPROMEPS.obj, output file: SPROMEPS.coff > >Converting from OMF32 to COFF32 <-------------------------------- > >Not adding or removing underscores for this filetype > >Warning 1211: 270 comment records ignored > > > >Do you have a 64 bit version of spromeps.obj? > > No, this is legacy code and is only for 32 bit applications. > SafeNet has created the driver for both 32 and 64 bit Windows, but the > 64 bit driver is still used for 32 bit applications (like mine). Has > always worked fine with the Delphi apps (used since end of the > 1990:s). > > They did not provide a SPROMEPS.obj file for 64 bit Delphi maybe > because that does not really exist yet (according to the Embarcadero > user forum the newly released 64 bit compiler is not ready for prime > time...) > > Question: > Could it be that Lazarus is anyway compiling for a 64 bit application > since it is installed on a 64 bit Windows 7 laptop? > I just assumed that the main application would be 32 bit as is the > case for Delphi.... > > But if I go into Project Options and look at Compiler Options -> > Config and Target -> Target-specific options there is a checkbox for > "Win32 gui application (-WG)" and it is checked. > > So I guess I am creating a Win32 exe as intended... > > > -- > Bo Berglund > Developer in Sweden > > > -- > _______________________________________________ > Lazarus mailing list > [email protected] > http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
-- _______________________________________________ Lazarus mailing list [email protected] http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
