Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-pascal / 2012-06

Win64 SEH patch fixes some Firebird embedded bugs

19 messages · 7 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Reinier Olislagers

Just compiled FPC with -dTEST_WIN64_SEH and noticed that fixes bugs 17360 Firebird database exceptions don't generate EIBDatabaseError but a general exception on 64 bit windows
21581: Firebird embedded x64 Windows: CreateDB fails with an exception

It may well also remove the need for the nasty workaround applied in bug 19116: RunError(32) when reading BLOB with IBConnection on Win64 ... which might also be interesting given Marco's remark:

* While reading up on the previous issue I saw warnings that getting the blob size this way might be notoriously slow.

Thought I'd let everybody know in case they run into Firebird x64 (embedded) problems on Windows and to indicate that implementing the SEH patch might be a good idea...

Thanks,
Reinier

Unknown author
to Reinier Olislagers
Reinier Olislagers wrote
Just compiled FPC with -dTEST_WIN64_SEH and noticed that fixes bugs 17360 Firebird database exceptions don't generate EIBDatabaseError but a general exception on 64 bit windows 21581: Firebird embedded x64 Windows: CreateDB fails with an exception

Great, you beat me to it :-)

Show quoted text 8 lines
It may well also remove the need for the nasty workaround applied in bug 19116: RunError(32) when reading BLOB with IBConnection on Win64 ... which might also be interesting given Marco's remark: > * While reading up on the previous issue I saw warnings that getting the blob size this way might be notoriously slow. Thought I'd let everybody know in case they run into Firebird x64 (embedded) problems on Windows and to indicate that implementing the SEH patch might be a good idea...

Well, I was going to test the above bugs and if they fixed the issue, recommend to enable SEH by default on Win64.

Michael.

Toru Takubo
to Reinier Olislagers: Just compiled FPC with -dTEST_WIN64_SEH and noticed that fixes bugs 17360 Firebird…
Reinier Olislagers wrote 5 lines
It may well also remove the need for the nasty workaround applied in bug 19116: RunError(32) when reading BLOB with IBConnection on Win64 ... which might also be interesting given Marco's remark: > * While reading up on the previous issue I saw warnings that getting the blob size this way might be notoriously slow.

What a good news! As a reporter I shall test it myself, but I would like to thank you in advance.

Toru Takubo

Reinier Olislagers
to Unknown author: Great, you beat me to it :-) Well, I was going to test the above bugs and if they fixed…
Show quoted text 7 lines
On Thu, 21 Jun 2012, Reinier Olislagers wrote: > Thought I'd let everybody know in case they run into Firebird x64 > (embedded) problems on Windows and to indicate that implementing the SEH > patch might be a good idea... Well, I was going to test the above bugs and if they fixed the issue, recommend to enable SEH by default on Win64.

Recommend away, I'd say ;)

Thanks,
Reinier

Alexis Halbot-Schoonaert
to Reinier Olislagers

Hello,

I try to debug a FastCGI (with a TWebModule) wich connects itself to FireBug in Lazarus and the debugger stops debugging when i do a connection to FireBird.
Ubuntu 12.04, FPC 2.6.0 Lazarus 0.9.30.4

I can see my SQLQueryresult at design time in Lazarus. Ok.

I can execute my FastCGI (outside Lazarus, so not debugging). The connection with Apache, the FastCGI execution with the FireBird connection and the result returned to the browser... Everything is Ok.

If a remove the DB connection in my code, i can debug the FastCGI. With the DB connection, the debugger goes away and apache goes to time out.

I encountered the same problem with a MySql connection several months ago, and didn't try until now.

the same problem happens in a console programme, as if the lack of graphical interface make the problem to happen.

If i write an lcl application with a dbgrid, and the same connection configuration, everything is Ok, including debugging.

Please, i don't want to use PHP! ;p

Thank you for your help!
Alexis

Sven Barth
to Alexis Halbot-Schoonaert

Please don't answer to an existing thread with a completely different topic as then you might not receive answers, because users either ignore such messages or think the message is for the given thread (because their threadview is collapsed and they only see that a new message arrived in that thread.

So please always send a mail for a new topic directly to the list without using "answer to all/list/sender".

Regards,
Sven

Alexis Halbot-Schoonaert wrote 35 lines
Hello, I try to debug a FastCGI (with a TWebModule) wich connects itself to FireBug in Lazarus and the debugger stops debugging when i do a connection to FireBird. Ubuntu 12.04, FPC 2.6.0 Lazarus 0.9.30.4 I can see my SQLQueryresult at design time in Lazarus. Ok. I can execute my FastCGI (outside Lazarus, so not debugging). The connection with Apache, the FastCGI execution with the FireBird connection and the result returned to the browser... Everything is Ok. If a remove the DB connection in my code, i can debug the FastCGI. With the DB connection, the debugger goes away and apache goes to time out. I encountered the same problem with a MySql connection several months ago, and didn't try until now. the same problem happens in a console programme, as if the lack of graphical interface make the problem to happen. If i write an lcl application with a dbgrid, and the same connection configuration, everything is Ok, including debugging. Please, i don't want to use PHP! ;p Thank you for your help! Alexis _______________________________________________ fpc-pascal maillist - http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Alexis Halbot-Schoonaert
to Sven Barth

Hello Sven

So please always send a mail for a new topic directly to the list without using "answer to all/list/sender".

oops ! I understood the problem. I can see some tags like In-Reply-To: in the header... So changing the title is not enough... Sorry...

Alexis.

silvioprog
to Alexis Halbot-Schoonaert: I try to debug a FastCGI (with a TWebModule) wich connects itself to FireBug in Lazarus…

2012/6/22 Alexis Halbot-Schoonaert :

Show quoted text 30 lines
Hello, I try to debug a FastCGI (with a TWebModule) wich connects itself to FireBug in Lazarus and the debugger stops debugging when i do a connection to FireBird. Ubuntu 12.04, FPC 2.6.0 Lazarus 0.9.30.4 I can see my SQLQueryresult at design time in Lazarus. Ok. I can execute my FastCGI (outside Lazarus, so not debugging). The connection with Apache, the FastCGI execution with the FireBird connection and the result returned to the browser... Everything is Ok. If a remove the DB connection in my code, i can debug the FastCGI. With the DB connection, the debugger goes away and apache goes to time out. I encountered the same problem with a MySql connection several months ago, and didn't try until now. the same problem happens in a console programme, as if the lack of graphical interface make the problem to happen. If i write an lcl application with a dbgrid, and the same connection configuration, everything is Ok, including debugging. Please, i don't want to use PHP! ;p Thank you for your help! Alexis

Hellow, :)

Hm... I use JDO (https://github.com/silvioprog/jdo) with CGI and works very well, please see this simple demo:

http://silvioprog.com.br/grid.html

JDO is a descendant project from SQLdb and is very similar to the PDO project, but has native support for JSON.

The source code of this project here:

http://code.google.com/p/lazarus-br/source/browse/#svn%2Ftrunk%2Fweb%2Flws-jdo-jeasyui

Silvio Clécio My public projects - github.com/silvioprog
Alexis Halbot-Schoonaert
to silvioprog
Show quoted text 7 lines
> I try to debug a FastCGI (with a TWebModule) wich connects itself to > FireBug in Lazarus and the debugger stops debugging when i do a > connection to FireBird. Hm... I use JDO (https://github.com/silvioprog/jdo) with CGI and works very well, please see this simple demo:

you mean that you can use the GDB debugger in lazarus with break points with JDO ?

Michael Van Canneyt
to Alexis Halbot-Schoonaert
Alexis Halbot-Schoonaert wrote 10 lines
>> I try to debug a FastCGI (with a TWebModule) wich connects itself to >> FireBug in Lazarus and the debugger stops debugging when i do a >> connection to FireBird. > > Hm... I use JDO (https://github.com/silvioprog/jdo) with CGI and works > very well, please see this simple demo: > you mean that you can use the GDB debugger in lazarus with break points with JDO ?

No. One has nothing to do with the other.

Michael.

Reinier Olislagers
to Unknown author: Great, you beat me to it :-) Well, I was going to test the above bugs and if they fixed…
Show quoted text 23 lines
On Thu, 21 Jun 2012, Reinier Olislagers wrote: > Just compiled FPC with -dTEST_WIN64_SEH and noticed that fixes bugs > 17360 Firebird database exceptions don't generate EIBDatabaseError but a > general exception on 64 bit windows > 21581: Firebird embedded x64 Windows: CreateDB fails with an exception Great, you beat me to it :-) > It may well also remove the need for the nasty workaround applied in bug > 19116: RunError(32) when reading BLOB with IBConnection on Win64 > ... which might also be interesting given Marco's remark: >> * While reading up on the previous issue I saw warnings that getting >> the blob size this way might be notoriously slow. > > Thought I'd let everybody know in case they run into Firebird x64 > (embedded) problems on Windows and to indicate that implementing the SEH > patch might be a good idea... Well, I was going to test the above bugs and if they fixed the issue, recommend to enable SEH by default on Win64. Michael.

Any news on this? (I haven't seen anything in the bug tracker or commit messages, but might have missed some)...

Thanks,
Reinier

Michael Van Canneyt
to Reinier Olislagers
Reinier Olislagers wrote 27 lines
On 21-6-2012 11:39, wrote: > On Thu, 21 Jun 2012, Reinier Olislagers wrote: > >> Just compiled FPC with -dTEST_WIN64_SEH and noticed that fixes bugs >> 17360 Firebird database exceptions don't generate EIBDatabaseError but a >> general exception on 64 bit windows >> 21581: Firebird embedded x64 Windows: CreateDB fails with an exception > > Great, you beat me to it :-) > >> It may well also remove the need for the nasty workaround applied in bug >> 19116: RunError(32) when reading BLOB with IBConnection on Win64 >> ... which might also be interesting given Marco's remark: >>> * While reading up on the previous issue I saw warnings that getting >>> the blob size this way might be notoriously slow. >> >> Thought I'd let everybody know in case they run into Firebird x64 >> (embedded) problems on Windows and to indicate that implementing the SEH >> patch might be a good idea... > > Well, I was going to test the above bugs and if they fixed the issue, > recommend to enable SEH by default on Win64. > > Michael. Any news on this? (I haven't seen anything in the bug tracker or commit messages, but might have missed some)...

Patience. These things take time.

I've set the weels in motion.

Michael.

Reinier Olislagers
to Michael Van Canneyt
Michael Van Canneyt wrote 22 lines
On Mon, 9 Jul 2012, Reinier Olislagers wrote: > On 21-6-2012 11:39, > wrote: >> On Thu, 21 Jun 2012, Reinier Olislagers wrote: >>> Thought I'd let everybody know in case they run into Firebird x64 >>> (embedded) problems on Windows and to indicate that implementing the >>> SEH >>> patch might be a good idea... >> >> Well, I was going to test the above bugs and if they fixed the issue, >> recommend to enable SEH by default on Win64. >> >> Michael. > > Any news on this? (I haven't seen anything in the bug tracker or commit > messages, but might have missed some)... Patience. These things take time. I've set the weels in motion. Michael.

Thanks.

I noticed some things do take time.. the thing is that without any feedback is hard to guess whether something was forgotten, or wheels are set in motion...

Let me put it another way: I've looked at mantis, the fpc mailing list and the fpc-devel mailing list... is there some other place people can keep track of this without having to pester devs to check whether their pet peeve has been fixed already... instead of yesterday, which is universally accepted as the proper date of implementing one's*) requests ;)

On the other hand, if this kind of communication takes place in personal emails back and forth or in another ad hoc/non-public fashion - totally fine by me... I'll just don my flame retardant suit and keep pestering people... with the best intentions ;)

Thanks,
Reinier

*) well.. mine... everybody else can wait ;)

Michael Van Canneyt
to Reinier Olislagers
Reinier Olislagers wrote 16 lines
> Patience. These things take time. > > I've set the weels in motion. > > Michael. Thanks. I noticed some things do take time.. the thing is that without any feedback is hard to guess whether something was forgotten, or wheels are set in motion... Let me put it another way: I've looked at mantis, the fpc mailing list and the fpc-devel mailing list... is there some other place people can keep track of this without having to pester devs to check whether their pet peeve has been fixed already... instead of yesterday, which is universally accepted as the proper date of implementing one's*) requests ;)

That would probably be a universe where the higgs-particle does not exist, and things can proceed at light speed.

To be clear: my remark was not meant as 'annoyed' or whatever. Laconic is more what I had in mind.

To anwser your question about the 'other place':

There is no other place. You did fine asking on this mailing list.

The sole reasons this takes time is that
a) it is a very invasive change, and we are by nature prudent. b) I am a busy man, and simply didn't bring up the subject yet as I had promised.

It would not do to just apply/enable every patch at the whim of a person. The compiler would become unstable/unusable very quickly, and there would be no end to the complaints.

But we'll get there.

Michael.

Reinier Olislagers
to Michael Van Canneyt
Michael Van Canneyt wrote 22 lines
On Mon, 9 Jul 2012, Reinier Olislagers wrote: >> Patience. These things take time. >> >> I've set the weels in motion. >> >> Michael. > Thanks. > > I noticed some things do take time.. the thing is that without any > feedback is hard to guess whether something was forgotten, or wheels are > set in motion... > > Let me put it another way: I've looked at mantis, the fpc mailing list > and the fpc-devel mailing list... is there some other place people can > keep track of this without having to pester devs to check whether their > pet peeve has been fixed already... instead of yesterday, which is > universally accepted as the proper date of implementing one's*) > requests ;) That would probably be a universe where the higgs-particle does not exist, and things can proceed at light speed.

Yep ;)

To be clear: my remark was not meant as 'annoyed' or whatever. Laconic is more what I had in mind.

I understand - likewise in mine I tried to inject some humor to indicate that I'm can still see the sunny side of things...

Show quoted text 8 lines
To anwser your question about the 'other place': There is no other place. You did fine asking on this mailing list. The sole reasons this takes time is that a) it is a very invasive change, and we are by nature prudent. b) I am a busy man, and simply didn't bring up the subject yet as I had promised.

Ok.

It would not do to just apply/enable every patch at the whim of a person. The compiler would become unstable/unusable very quickly, and there would be no end to the complaints.

I never suggested anybody do that.

OTOH, the change in question is a fix for multiple known issues and as far as I know has no bad side effects.

That's why I would have thought that, if the compiler test suite results are ok, applying it to FPC trunk would be the ideal way to have more people check if there are indeed no side effects.

Still, I'm sure we agree about the pros and cons in general... it's a matter of preference how agressive/prudent you want to be and I'm not an FPC dev so the decision isn't mine to take and the only thing I can do is politely suggest and then back off ;)

But we'll get there.

I'll leave you guys to it, then ;)

Thanks,
Reinier

Michael Van Canneyt
to Reinier Olislagers
Reinier Olislagers wrote
> But we'll get there. I'll leave you guys to it, then ;)

It turns out there are reasons not to enable it by default just yet:

Major issue 1: ld randomly crashes while linking any executable with .pdata section. When it crashes, Windows pops up the WER dialog, meaning that the entire testsuite will hang until it is dismissed manually.

Major issue 2: I used dummy relocations to link in required .pdata sections, but this cannot be expressed using gas. This means either smartlinking should be disabled with gas, or the entire .pdata will be dropped, making SEH unusable.

Enabling it by default would mean that we can no longer compile the textmode ide, and running the testsuite automatically would become impossible.

So until these issues are addressed, the SEH will not be included as the default mechanism.

Michael.

Reinier Olislagers
to Michael Van Canneyt
Michael Van Canneyt wrote 21 lines
It turns out there are reasons not to enable it by default just yet: Major issue 1: ld randomly crashes while linking any executable with .pdata section. When it crashes, Windows pops up the WER dialog, meaning that the entire testsuite will hang until it is dismissed manually. Major issue 2: I used dummy relocations to link in required .pdata sections, but this cannot be expressed using gas. This means either smartlinking should be disabled with gas, or the entire .pdata will be dropped, making SEH unusable. Enabling it by default would mean that we can no longer compile the textmode ide, and running the testsuite automatically would become impossible. So until these issues are addressed, the SEH will not be included as the default mechanism.

Thanks a lot for the update,

regards,
Reinier

Sven Barth
to Michael Van Canneyt: It turns out there are reasons not to enable it by default just yet: Major issue 1: ld…
Michael Van Canneyt wrote 5 lines
Major issue 2: I used dummy relocations to link in required .pdata sections, but this cannot be expressed using gas. This means either smartlinking should be disabled with gas, or the entire .pdata will be dropped, making SEH unusable.

You even copied the "I" after the ":" instead of changing it to "Sergei" ;)

Regards,
Sven

Michael Van Canneyt
to Sven Barth
Sven Barth wrote 8 lines
On 09.07.2012 14:22, Michael Van Canneyt wrote: > Major issue 2: I used dummy relocations to link in required .pdata > sections, but this > cannot be expressed using gas. This means either smartlinking should be > disabled with gas, or the > entire .pdata will be dropped, making SEH unusable. You even copied the "I" after the ":" instead of changing it to "Sergei" ;)

Blast :/ I hadn't noticed.

Indeed. To all concerned: Sergei Gorelkin implemented SEH in the FPC compiler/RTL, and the quoted text was from him, of course.

Michael.