|
Home > Archive > SQL Anywhere database > August 2005 > Communication error/problem (actually external function problem?)
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Communication error/problem (actually external function problem?)
|
|
| Dave Foulkes 2005-07-07, 9:23 am |
| I still have no idea why the database server shuts itself down silently - no
error message, assertion or anything indicating a problem. The cause seems
to be two simultaneous calls to an external function in a DLL; one comes
from the connect event handler, the other from a login procedure. I can only
assume that something goes wrong during these simultaneous-ish calls,
causing the server to stop. Is there anything I should be doing within the
DLL to ensure that multiple simultaneous calls are handled properly, or
should the server itself be handling the situation?
Dave.
"Dave Foulkes" <dave.foulkes@NO.SPAM.tesco.net> wrote in message
news:42caa1e3@forums
-1-dub...
> Thank you for your response - your analysis is spot on. I've just
> discovered
> that an external function called by the login procedure is silently
> killing
> the server - no error message, nothing. Quite why this is happening I have
> no idea - yet. I'll report back when I know more.
| |
| Nick Elson 2005-07-07, 11:23 am |
| What exactly does your DLL do at those times?
It is entirely possible you have:
- created a deadlock or
- committed some sort of OS exception (an access
violation maybe?).
- It may even be possible that you are executing a
program exit directly.
- 3rd party libraries may also be suspect.
- Of course 'call conventions' are everything
here too.
You might want to log things to the server's output log
immediately before those calls. That may help you to
narrow down which call and which function is leading
up to this.
O\W about the only suggest I could make is suggesting
you try running the server in the foreground and see if
an exception shows up that way. [that and check
out all of your Event logs at/around the time of the exit]
If need be, open up a support case to provide more
details and your DLL example of the failure. [Either
way include exact versions, build, development environment
for your DLL, source of the functions coded, ..... and
exact usage information; especially around the times it
fails]
"Dave Foulkes" <dave.foulkes@NO.SPAM.tesco.net> wrote in message
news:42cd2764$1@foru
ms-2-dub...
>I still have no idea why the database server shuts itself down silently -
>no error message, assertion or anything indicating a problem. The cause
>seems to be two simultaneous calls to an external function in a DLL; one
>comes from the connect event handler, the other from a login procedure. I
>can only assume that something goes wrong during these simultaneous-ish
>calls, causing the server to stop. Is there anything I should be doing
>within the DLL to ensure that multiple simultaneous calls are handled
>properly, or should the server itself be handling the situation?
>
> Dave.
>
>
> "Dave Foulkes" <dave.foulkes@NO.SPAM.tesco.net> wrote in message
> news:42caa1e3@forums
-1-dub...
>
>
| |
| Dave Foulkes 2005-07-07, 11:23 am |
| The DLL function essentially provides the same functionality as the Win32
FindWindow - namely return the handle of a window of the given class and
name. The return value is used to decide whether or not to output debug
information.
Everything works absolutely fine with 704, but with 803 and 902 the server
(actually dbeng8/9) quietly goes away. Usually when one of my external
functions causes an exception (I'm running on Windows XP Professional SP2)
the OS leaves me in no doubt that something has gone wrong. That's what's so
puzzling - that the server disappears silently. There is nothing in the
server's output log nor the system's event log.
My workaround is to output the debug information unconditionally for now. If
I get the time I'll try to whittle it down to a small reproducible sample
and post it.
Dave.
"Nick Elson" < no_spam_nicelson@syb
ase.com> wrote in message
news:42cd43b4$1@foru
ms-2-dub...
> What exactly does your DLL do at those times?
>
> It is entirely possible you have:
>
> - created a deadlock or
> - committed some sort of OS exception (an access
> violation maybe?).
> - It may even be possible that you are executing a
> program exit directly.
> - 3rd party libraries may also be suspect.
> - Of course 'call conventions' are everything
> here too.
>
> You might want to log things to the server's output log
> immediately before those calls. That may help you to
> narrow down which call and which function is leading
> up to this.
>
> O\W about the only suggest I could make is suggesting
> you try running the server in the foreground and see if
> an exception shows up that way. [that and check
> out all of your Event logs at/around the time of the exit]
>
> If need be, open up a support case to provide more
> details and your DLL example of the failure. [Either
> way include exact versions, build, development environment
> for your DLL, source of the functions coded, ..... and
> exact usage information; especially around the times it
> fails]
>
> "Dave Foulkes" <dave.foulkes@NO.SPAM.tesco.net> wrote in message
> news:42cd2764$1@foru
ms-2-dub...
>
>
| |
| Erik Anderson 2005-07-07, 11:23 am |
| If you do manage to track down the cause, I would appreciate some idea that
could cause silent shutdowns such as this. I have been dealing for some
time with a similar situation where an external function succeeds until the
next proxy table access, after which a silent shutdown occurs. As far as I
can guess a silent shutdown would happen if the application is so badly
corrupted that it does not have the ability to show an error message on the
screen, but I don't know what could cause this to happen inside of ASA.
"Dave Foulkes" <dave.foulkes@NO.SPAM.tesco.net> wrote in message
news:42cd54ce@forums
-1-dub...
> The DLL function essentially provides the same functionality as the Win32
> FindWindow - namely return the handle of a window of the given class and
> name. The return value is used to decide whether or not to output debug
> information.
>
> Everything works absolutely fine with 704, but with 803 and 902 the server
> (actually dbeng8/9) quietly goes away. Usually when one of my external
> functions causes an exception (I'm running on Windows XP Professional SP2)
> the OS leaves me in no doubt that something has gone wrong. That's what's
> so puzzling - that the server disappears silently. There is nothing in the
> server's output log nor the system's event log.
>
> My workaround is to output the debug information unconditionally for now.
> If I get the time I'll try to whittle it down to a small reproducible
> sample and post it.
>
> Dave.
>
> "Nick Elson" < no_spam_nicelson@syb
ase.com> wrote in message
> news:42cd43b4$1@foru
ms-2-dub...
>
>
| |
|
| There is a fix for this on Sybase 9... I Had similar problem when calling a
DLL developed in Delphi (Borland compiler)...
modify the follwingfollowing call
function GetCode: Integer; stdcall; export;
const // <---- need this line
of code to avoid problem with Sybase
MCW_EM : Longword = $133f; // <---- need this line of code to avoid
problem with Sybase
begin
try
Set8087CW(MCW_EM); // <---- need this line of code to avoid
problem with Sybase
{your code here}
except
result := 0;
end;
end;
Luis
"Erik Anderson" < erikba@teamworkgroup
.com> wrote in message
news:42cd5e4c$1@foru
ms-2-dub...
> If you do manage to track down the cause, I would appreciate some idea
> that could cause silent shutdowns such as this. I have been dealing for
> some time with a similar situation where an external function succeeds
> until the next proxy table access, after which a silent shutdown occurs.
> As far as I can guess a silent shutdown would happen if the application is
> so badly corrupted that it does not have the ability to show an error
> message on the screen, but I don't know what could cause this to happen
> inside of ASA.
>
> "Dave Foulkes" <dave.foulkes@NO.SPAM.tesco.net> wrote in message
> news:42cd54ce@forums
-1-dub...
>
>
| |
| Erik Anderson 2005-08-22, 1:23 pm |
| An interesting solution, not sure how it ports though. VC++ says that it
"disables FPU exceptions by default", but that doesn't involve external DLL
references, the equivalent command in VC seems to be "_controlfp". As far
as I know I'm not using any FPU operations in my logic though and I doubt if
the op's FindWindow call is using FPU operations, but it could be an
interesting angle to look into...
FYI, I would *highly* recommand that you put any global FPU settings back
the way you found them when you came in.
"Luis" <Luis@noemail.com> wrote in message news:4309e932$1@foru
ms-2-dub...
> There is a fix for this on Sybase 9... I Had similar problem when calling
> a DLL developed in Delphi (Borland compiler)...
>
> modify the follwingfollowing call
>
> function GetCode: Integer; stdcall; export;
> const // <---- need this
> line of code to avoid problem with Sybase
> MCW_EM : Longword = $133f; // <---- need this line of code to avoid
> problem with Sybase
> begin
> try
> Set8087CW(MCW_EM); // <---- need this line of code to avoid
> problem with Sybase
> {your code here}
> except
> result := 0;
> end;
> end;
>
> Luis
>
> "Erik Anderson" < erikba@teamworkgroup
.com> wrote in message
> news:42cd5e4c$1@foru
ms-2-dub...
>
>
| |
|
| Actually my code does not use floating point either...
I had that problem and sybase eng. team help me with it... they fixed the
problem on one patch of Asa9, but I'm not sure if they did a patch for
previous version..
function YourFunction: Integer; stdcall; export;
const
MCW_EM : Longword = $133f;
var
Saved8087CW: Word;
begin
try
Saved8087CW := Default8087CW;
Set8087CW(MCW_EM);
{Your Code...}
Set8087CW(Saved8087C
W);
except
result := 0;
end;
end;
Luis
"Erik Anderson" < erikba@teamworkgroup
.com> wrote in message
news:430a0f08$1@foru
ms-1-dub...
> An interesting solution, not sure how it ports though. VC++ says that it
> "disables FPU exceptions by default", but that doesn't involve external
> DLL references, the equivalent command in VC seems to be "_controlfp". As
> far as I know I'm not using any FPU operations in my logic though and I
> doubt if the op's FindWindow call is using FPU operations, but it could be
> an interesting angle to look into...
>
> FYI, I would *highly* recommand that you put any global FPU settings back
> the way you found them when you came in.
>
> "Luis" <Luis@noemail.com> wrote in message news:4309e932$1@foru
ms-2-dub...
>
>
| |
| Nick Elson 2005-08-22, 8:23 pm |
| Luis,
Check out the latest bug fixes. A couple could apply but this
one sounds like it covers the ground you are having problems
with.
================<B>(Build #3099 - Engineering Case
#383178)</B>================
The server disables floating point exceptions by default. If an external
function DLL written in Delphi was used, floating point exceptions could
have been enabled. This could have lead to a subsequent server crash due
to a floating point exception. This has been fixed.
So go and test with 9.0.2 some build 3099 or higher and see
if that is it.
"Luis" <Luis@noemail.com> wrote in message news:430a1c47$1@foru
ms-1-dub...
> Actually my code does not use floating point either...
>
> I had that problem and sybase eng. team help me with it... they fixed the
> problem on one patch of Asa9, but I'm not sure if they did a patch for
> previous version..
>
> function YourFunction: Integer; stdcall; export;
> const
> MCW_EM : Longword = $133f;
> var
> Saved8087CW: Word;
> begin
> try
> Saved8087CW := Default8087CW;
> Set8087CW(MCW_EM);
> {Your Code...}
> Set8087CW(Saved8087C
W);
> except
> result := 0;
> end;
> end;
>
>
> Luis
>
>
> "Erik Anderson" < erikba@teamworkgroup
.com> wrote in message
> news:430a0f08$1@foru
ms-1-dub...
>
>
|
|
|
|
|