| Author |
Message
|
| ant |
 Posted: Wed Nov 21, 2001 10:48 am Post subject: |
 |
|
Newbie
Joined: 20 Nov 2001
Posts: 4
|
I am using a VB DLL to call MQ Client 5.1 on Win NT4 ( SP6 ) workstations. The DLL is invoked from Siebel 2000 to handle messaging to MVS legacy systems.
Approximately 0.1% to 0.5% of calls to this DLL result in MQCONN crashing the MQClient and hence the DLL and Siebel.
The appears to be no common factor about the crashes and no way to get a handle on why they occur.
The only evidence is a Windows 'Exception Caught' dialog reporting:
"Unexpected exception 0xc00000005: access
violation reading from address 0x0016c000"
"Module: c:program filesmqseries clientbinamqrmqia.dll"
"address: 91D11BE ( no debug info )"
"The first stack frame is corrupt!!"
It then points one to the Event Viewer for more information - but no Event has been logged.
Anyone any ideas ? Is this a known issue requiring a patch ?
_________________
Life is like a sewer: what you get out of it depends on what you put in to it. |
|
| Back to top |
|
 |
| kolban |
| Posted: Wed Nov 21, 2001 2:52 pm Post subject: |
|
|
Grand Master
Joined: 22 May 2001
Posts: 1072
Location: Fort Worth, TX, USA
|
| The first thing I would do is to start an MQSeries trace (Client side) and see if you can capture a failure. By virtue of the fact that it is very non-deterministic, I am immediately suspicious about threading. Are you attempting to call the MQ APIs from multiple threads at the same time using the same connection handle? |
|
| Back to top |
|
|
| ant |
| Posted: Thu Nov 22, 2001 1:30 am Post subject: |
|
|
Newbie
Joined: 20 Nov 2001
Posts: 4
|
I have been tempted to use trace but on any individual workstation the error only happens around once a week and the traces can get rather large.
the application is not thread enabled. each call to the DLL is completely discrete creating and using a whole new connection ( with new handle ) that is discarded at the end of the dialog - yes, not the most efficient way to do it - but encapsulated.
at the same time that this process can be called there is another MQ connection open from the same client - this connection remains open for the whole duration of the parent (Siebel) application session and does not have a similar problem.
is there a problem having multiple concurrent connections from an MQ Client ? |
|
| Back to top |
|
|
| kolban |
| Posted: Mon Nov 26, 2001 9:54 am Post subject: |
|
|
Grand Master
Joined: 22 May 2001
Posts: 1072
Location: Fort Worth, TX, USA
|
There should be no problem at all with having multiple connections open from the same NT/2000 process.
Could you stub a driver for your DLL that calls it repeatedly in a tight loop and see if the problem can recreate much faster? |
|
| Back to top |
|
|
| bower5932 |
| Posted: Mon Nov 26, 2001 1:39 pm Post subject: |
|
|
Jedi Knight
Joined: 27 Aug 2001
Posts: 3023
Location: Dallas, TX, USA
|
| I found one hit that looks like it might be related to what you are seeing. Basically, it said to make sure that you filled in all 48 characters of the Qmgr name (padding if necessary). |
|
| Back to top |
|
|
| ant |
| Posted: Tue Nov 27, 2001 9:38 am Post subject: |
|
|
Newbie
Joined: 20 Nov 2001
Posts: 4
|
I like Kolbans' stub idea - thanks - I'll give it a whirl.
I saw the 48 characters item - but thought "this is VB - and its a fixed length string in the MQ _DEFAULTS underlying definition so any characters moved in there should attract implied trailing spaces to the end of the string up to the Max size." |
|
| Back to top |
|
|
| farteau |
| Posted: Wed Nov 28, 2001 8:32 am Post subject: |
|
|
Newbie
Joined: 27 Nov 2001
Posts: 2
Location: Quebec (Canada)
|
Hi,
I am having the same exact problem than you and I'm still looking for answers.
Did you find something to fix your problem? |
|
| Back to top |
|
|
| ant |
| Posted: Mon Dec 03, 2001 9:55 am Post subject: |
|
|
Newbie
Joined: 20 Nov 2001
Posts: 4
|
Well I tried the loop and the process refuses to fail under test conditions on many hundreds of iterations.
As time was short - I decided to rework this process so it grabs and uses the MQ Queues which are held open by the other running process I mentioned ( since they are exposed as public objects ).
This seems to avoid rather than cure the issue I was having. |
|
| Back to top |
|
|
|
|
