LazSqlX

[BigChimp]

Could you try testing setting the linker to the external linker by setting -Xe in project options/other and see if debugging/running is ok?

Before there was an internal linker, an external linker was used. On other platforms, it is still used (see thread in fpc-devel from me on that subject).
So it had been working fine at some time at least.

[Mike.Cornflake]

Fair enough.  I don't see why it isn't working then. 

I've found how jwawinuser is linked into the app though.  Through MouseAndKeyInput, which uses JwaWinUser which in turn uses jwawinuser. (Idiot last part of sentence, please ignore :-) )

[Mike.Cornflake]

OK, I've got External Linker working.

Remove LazMouseAndKeyInput from Project Dependencies
Hit Compile.  Work your way through the errors.  99% of them are simply Uses that look like they can be removed.
When you get to LazSQLXCtrls.pas, comment out the following code.

Code: [Select]

  //case key of
  //VK_OEM_PERIOD:
  //  begin
  //    s:='';
  //
  //    KeyInput.Apply([ssCtrl]);
  //    try
  //      KeyInput.Press(VK_SPACE);
  //    finally
  //      KeyInput.Unapply([ssCtrl]);
  //    end;
  //
  //    if Assigned(FOnLastWordChanged) then
  //    FOnLastWordChanged(s);
  //
  //  end;
  //  VK_OEM_COMMA: KeyInput.Press(VK_SPACE);
  //end;
After that, the app at least builds and runs and debug etc works.

What damage I did getting it this far... :-)   

My instincts is that the Query Designer used to use JEDI MouseAndKeyInput, so perhaps only that is the affected bit...

Hopefully you get this working with the internal linker, and you don't need to do the above hack.

[BigChimp]

Yep. Meanwhile, from my end, got latest lazsqlx & compiled with FPC 2.6.4, laz trunk (regular internal linker). Seeing the same animated gif header exception as you.
Running the application stand alone does not give the opengl crash anymore...

Re keycode: seems its trying to replace . with Ctrl-Space - for variable completion I suppose - e.g. in Table.FieldName? Just guessing. May be better solved by setting a flag and testing for that flag in the code completion part (if any)?

For now, I'm going to focus on getting my file import code up to shape so I can provide a patch to flamer0n... and let's see what his opinion is regarding this mouse and keyboard stuff. I'd be happy to work on that next.

Thanks for all the help!

[BigChimp]

What IS this? Have I attracted some bad juju or something?

Debugging my data importer form changes, I get a SIGSEGV stepping through this code:

Code: [Select]

function TDbConnectionInfo.ToZeosConnection
...
   if FDbType = dtOracle then
... fdbtype exists and is dtFirebirdd.
... next run the sigsegv is a couple of lines below that in an equally innocuous piece of code.

Argh!

Why on earth can that code create a SIGSEGV?

I think I'm giving up on this for a while and try and clean up my entire Laz/FPC installs, sacrifice a chicken facing South, and drink some coffee...

[taazz]

What IS this? Have I attracted some bad juju or something?

Debugging my data importer form changes, I get a SIGSEGV stepping through this code:

Code: [Select]

function TDbConnectionInfo.ToZeosConnection
...
   if FDbType = dtOracle then
... fdbtype exists and is dtFirebirdd.
... next run the sigsegv is a couple of lines below that in an equally innocuous piece of code.

Argh!

Why on earth can that code create a SIGSEGV?

I think I'm giving up on this for a while and try and clean up my entire Laz/FPC installs, sacrifice a chicken facing South, and drink some coffee...

I'm betting that the external linker (or debug information) is the one to blame try to ignore what ever the IDE shows you and open the call stack window (ctrl+alt+S) and go from there try to find the first line of code inside SQLX application in the stack and see what you can surmise from that.

PS.
You never make any sacrifices facing south, you get the best results facing east or west depending on your religion (Christians prefer east), that might be your problem try again after you have sacrficed something better than a chicken facing east (Christians prefer lambs).

[BigChimp]

I'm betting that the external linker (or debug information) is the one to blame

No, I'm not using the external linker. See post above my last one.

try to ignore what ever the IDE shows you and open the call stack window (ctrl+alt+S) and go from there try to find the first line of code inside SQLX application in the stack and see what you can surmise from that.

That shows basically nothing (some line with the infamous question marks).

You never make any sacrifices facing south, you get the best results facing east or west depending on your religion (Christians prefer east), that might be your problem try again after you have sacrficed something better than a chicken facing east (Christians prefer lambs).

Good advice! I'll see what I can do
Edit: how many pigeons equal one lamb?

[Mike.Cornflake]

You never make any sacrifices facing south, you get the best results facing east or west depending on your religion (Christians prefer east), that might be your problem try again after you have sacrficed something better than a chicken facing east (Christians prefer lambs).

At uni nothing worked until we'd sacrificed a chicken sandwich.  As I've grown older, I see now this was stupid childish wish fulfillment. 

Widdershins is the real truth!  You need to turn widdershins 4 times, or it's all to naught...  (Or call one of the Elder Programmers over to see why some code doesn't work.  It ALWAYS works when they're around...)

[BigChimp]

Widdershins is the real truth!  You need to turn widdershins 4 times, or it's all to naught...  (Or call one of the Elder Programmers over to see why some code doesn't work.  It ALWAYS works when they're around...)

Mmm. I get seasick, so let's try the other way.
Have set debugger project options to -g -godwarfsets2; could also be -gw2 for dwarf (default is -g, stabs)
Using zeos testing

Attached form .pas & lfm to replace existing; fileimport.pas goes into UtilClasses.

Tried on laz trunk+FPC trunk; now get better working stack trace - perhaps the problem is in Zeos as that is the last line hit.. Pfff.. Would appreciate a look from one of you Elder Programmers, thanks

Edit: Mike caught an error of mine: add

Code: [Select]

  if not(assigned(FDestQuery)) then
    FDestQuery := TZQuery.Create(nil);
  assert(assigned(FDestQuery));
before

Code: [Select]

  FDestQuery.Connection := FConn;
... blush ....

Still crashes though.

[Mike.Cornflake]

Would appreciate a look from one of you Elder Programmers, thanks

Sorry - we investigated virtualising an Elder Programmer several ways over several years.  Nothing worked consistently.  The Elder Programmer first has to mumble about does he really need to come over, then he actually has to grumble his way over and stare pointedly at you.  And of course, at this point the code works - no matter how badly it was AV'ing prior to the call.

Oddly enough.  You don't always need an Elder Programmer.  Turns out, Gavin will do nicely.  We only had the one Gavin though, so were unsure if the phenomena was specific to him, or Gavin's in general...

Would appreciate a look from one of you Elder Programmers, thanks

What?  Oh that again.  Right, mumbling and grumbling's out of the way now, let's have a look...   I'll get back to you...

[BigChimp]

Hah. Your post worked - just invoking Gavin or The Elder Programmer gave the inspiration:
... Edit: nah, that was Zeos ignorance speaking I think...

Come on over, you grumbling bearded one!

[taazz]

try to ignore what ever the IDE shows you and open the call stack window (ctrl+alt+S) and go from there try to find the first line of code inside SQLX application in the stack and see what you can surmise from that.

That shows basically nothing (some line with the infamous question marks).

That is the trademark of no debug information which in turn it means that you either did not enable the "create debug information" or that the clean up failed and you are still using non debug units.
when I say the "clean up failed" I do include the chance of double .ppu/.o etc files on different directories and picking up the wrong one when linking.

You never make any sacrifices facing south, you get the best results facing east or west depending on your religion (Christians prefer east), that might be your problem try again after you have sacrficed something better than a chicken facing east (Christians prefer lambs).

Good advice! I'll see what I can do
Edit: how many pigeons equal one lamb?

well if you go by the weight a lamb weights around 80Kg a pigeon weights 200grams or something along those lines add an other 20Kg on the mid weight of the lamb for the innocent difference (lamb being the most innocent aka clean animal) and you have an answer but keep in mind that the innocent difference is just an estimation at this point, I do not know if they will be accepted instead of the lamb and depending on the size of the problem one lamb might not be enough. 

[BigChimp]

try to ignore what ever the IDE shows you and open the call stack window (ctrl+alt+S) and go from there try to find the first line of code inside SQLX application in the stack and see what you can surmise from that.

That shows basically nothing (some line with the infamous question marks).

That is the trademark of no debug information which in turn it means that you either did not enable the "create debug information" or that the clean up failed and you are still using non debug units.

Or the sigsegv messed up the debug info in memory...

Edit: or an FPC bug that messes up the debug info in case of mixed stabs and dwarf exists (e.g. in a package in Lazarus or LCL). There used to be one, don't know if it's closed already....

Edit2: However, did a clean & build all, set a breakpoint before the crash. Looked at call stack: fine. Continued to crash, looked at call stack

Code: [Select]

#0 ?? at :0
#1 endthreadex at :0
#2 ?? at :0
#3 ?? at :0
#4 ?? at :0
threading related!?!
Edit3: )(*@#$)(*()@*%*@% using FPC 2.6.4+new Firebird embedded dll to connect to remote db=> gives problems because Firebird devs changed code which used to work. Workaround is in trunk but not 2.6.x. Perhaps that's relevant...=> replacing with old Fbembed.dll version 2.5.0 works!!!!!

Thanks guys... on to the next problem

[Mike.Cornflake]

Edit3: )(*@#$)(*()@*%*@% using FPC 2.6.4+new Firebird embedded dll to connect to remote db=> gives problems because Firebird devs changed code which used to work. Workaround is in trunk but not 2.6.x. Perhaps that's relevant...=> replacing with old Fbembed.dll version 2.5.0 works!!!!!

@flameron has already provided all the required lib files in LazSQLx\Windows_Libs.  I see fbclient25.dll is in that collection :-)

[marcov]

Why on earth can that code create a SIGSEGV?

Any first field reference in a method can crash if the instance is not allocated or corrupt. If you typecast any pointer to a class and then run methods on it, chances are the crash behaviour will look like this. This is no different from Delphi btw.

And keep in mind that assigned() is only a test for zero, not general validity.