Re: Perplexing Problem - Need Help

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance


"dpb" <none@xxxxxxx> wrote in message
news:h2vv7q$ot6$1@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx

I'd wager if a stack is being popped incorrectly, it's somewhere in one of
these procedures, _not_ having to do w/ the file deletion itself.

Are these event handlers your code or part of the 3rd party software
support for the scanner?

Some of both. The scan OCX, part of the Kodak Imaging professional (used to
be the Wang Imaging components shipped with Windows pre XP), was not
allowing the App to process other events or properly run the code that
allows the scan operator to review every n pages scanned when instantiated
directly in the application. This was a hard requirement that I could not
change. To get around that I wrapped the scan OCX into and ActiveX EXE so I
could get asynchronous operation. The events are raised by the OCX and are
then raised back to the application by the ActiveX EXE.

Any use of an API removes you (as I'm sure you know; just emphasizing) the
VB protection and ability to check for stack alignment, number of
arguments, etc., etc., ... I'd still be suspicious of a problem in a case
where the scanner may not have done _quite_ the right thing and there's a
problem that isn't being handled correctly. Just what that might be, of
course, I have no clue w/o any more knowledge, it's just that the symptoms
(at least as I think I hear) seem to be associated with a case where the
document didn't get processed correctly by the rest of the app--that makes
me think the document itself may not have gotten generated in pristine
form which makes me wonder if there's not some extra or lacking piece of
data flowing or not flowing around in these non-native portions of the
code.

All valid suspicions. The Assembly routine is the third routine called in
the Scan_Done event procedure. There are calls to a Barcode Detection
procedure followed by a Blank Page Detection procedure. There are a few
other minor calls as well, before the call to the Assembly routine. All
three of these procedures loop through all of the pages in the batch and do
some processing using the object model exposed by the DLL. The Barcode
Detection procedure uses a 3rd party API and actually processes the data in
each scanned TIF file. All three of these procedures log the call and
returns to the error log file. The first two have never failed.

All of that is to say that the call stack has been thoroughly exercised
after the scan_done event is raised by the scanner and before the Assembly
procedure is called. That is why I believe that the issue has to be
somewhere in the Assembly procedure or the file/folder handling code of the
DLL.


Maybe but I think it's deeper down than that...

I just wish I could come up with a test cast that would reliably cause the
code to fail. At this point it seems to be completely random and non
repeatable.

I'm suggesting that perhaps somewhere in the case of a problem what you
think is appropriate error handling/fixup just might not be so. If you
ran for a while w/o any error trapping perhaps the runtime would barf
differently than you expect...

True, but even if the error handling is not appropriate and given that I
have a pretty standard error handler, the error handler should be entered
for any error that can be handled by VB. The entry to the error handler is
logged as well as the exit from the procedure. Neither one gets logged when
the error occurs. Errors that cannot be handled usually pop a message box
and the app crashes. This is not happening. It just appears that the stack
is being improperly popped.

If you're not used the "assume no aliasing" compiler switch the problem
mentioned before won't bite you. Let's not throw any more spurious things
into the mix if you haven't used it... :)

--

Thanks again for your input.

--
Al Reid


.

Relevant Pages

  • Re: Exception Handling...
    ... >>The try key word results in the current stack frame base, ... > private data on top of the Exception Registration... ... is the address of the exception handler. ... >>Immediately following this jump, there is inserted a jump to ...
    (comp.lang.pascal.delphi.misc)
  • Re: Fw: Re: [PATCH 1/3] signal(i386): alternative signal stack wraparound occurs
    ... detect when it would itself be causing a stack overflow. ... When it's the handler function itself or its callees that cause the ... signal stack based on the value of the SP at the time of a signal. ...
    (Linux-Kernel)
  • Re: patches for kForth signals interface
    ... If a Forth word is installed as a signal handler, when the OS executes the handler, the stack state is in an unpredictable condition, i.e. the switch may have occured during the middle of execution of a word. ... \ Test for stack overwrite problem in kForth 1.3.1 signals interface, ...
    (comp.lang.forth)
  • Re: Question on the airport delays stuff
    ... In France when a baggage handler takes out a scanner, ... The advent of registering smaller items (such as PC's, mobile phones, ...
    (uk.rec.motorcycles)
  • Re: VLA failure
    ... (with help from several comp.std.c regulars) ... ago, loosely based on setjmp/longjmp: ... Behavior is undefined if there is a stack exception in the function ... Why does __stackjmp_restoreset a default handler instead of no ...
    (comp.std.c)