Obscure bug finally found 
Author Message
 Obscure bug finally found

I'm new to this group, but I thought I'd post a problem I just found in one
of my projects.  I've been trying to hunt down this particular bug for
weeks.

My project is in VB5, and after compiling and testing it out, it would
always crash.  The problem was though it crashed randomly, sometimes after
running for a few minutes, sometimes several hours (with the same load).
Sometimes it would simply crash to the desktop with no error message at all,
sometimes with an "Access Violation", sometimes with "Stack Fault", and
sometimes even with "Illegal Procedure Call".

I put in tons of debug code, was writing to a text file every time I entered
and left every function.  I found it was crashing randomly in different
functions, and I was unable to track it down to any particular function.

Anyhow, I've been coding in VB for 11 years (since v1.0), and this was very
frustrating.  Add to that if I compiled the code in "P-Code" my project
worked flawlessly!  But I found it.  One of my functions requires an array
as an argument, easy right?  Well, I thought I'd save a step in creating the
array before I passed it and just create it *as* I pass it:

    Call SomeFunction(Array("one","two","three"))

instead of:

    aArray = Array("one","two","three")
    Call SomeFunction(aArray)

I'm hoping someone here can confirm what I think was/is happening.  VB5
passes all parameters by reference by default.  Normally of course this
isn't a problem.  But when I was passing  Array("one","two","three") as an
argument, VB was creating a temporary reference for the result.  I don't
know if it was pushed onto the stack, or put in memory somewhere, but it was
probably marked somehow as "temporary" with an unknown lifespan.  I'm
assuming that during normal VB memory/stack "garbage collection" it was
being destroyed, and causing major problems even if the reference wasn't in
use anymore.  I also assume that this "garbage collection" was the reason
why the program was sometimes running for minutes and sometimes hours before
crashing.  When the program was compiled in "P-Code", I think VB handles all
variables and parameters a little different, and thus my program didn't
crash.

Now that I've removed using "Array()" as a parameter I'm passing, the
program works flawlessly compiled to "native code".  Sorry for the long
post, but I'm hoping to spare someone else the pain I went through in
tracking this problem down.  I'm also hoping to get some help from someone
knowledgeable in the internals of VB to explain why this was happening, and
if my assumptions are correct.

Thanks,
S. Murray



Sat, 11 Sep 2004 15:26:00 GMT  
 Obscure bug finally found

Quote:

> I'm hoping someone here can confirm what I think was/is happening.  VB5
> passes all parameters by reference by default.  Normally of course this
> isn't a problem.  But when I was passing  Array("one","two","three") as an
> argument, VB was creating a temporary reference for the result.  I don't
> know if it was pushed onto the stack, or put in memory somewhere, but it was
> probably marked somehow as "temporary" with an unknown lifespan.  I'm
> assuming that during normal VB memory/stack "garbage collection" it was
> being destroyed, and causing major problems even if the reference wasn't in
> use anymore.  I also assume that this "garbage collection" was the reason
> why the program was sometimes running for minutes and sometimes hours before
> crashing.  When the program was compiled in "P-Code", I think VB handles all
> variables and parameters a little different, and thus my program didn't
> crash.

Because VB6 finalization really is deterministic, I'd be more inclined
to think the actual problem lies elsewhere.  Timing, for example, of
exactly when the Array() function gets called.  It might even be getting
a separate call with each reference in the called code, if somehow what's
getting passed is analogous to a procedure reference instead of a data one.
So then you might have separate copies of the array.  Though if there
weren't any side-effects they should be data-identical.

But nothing at all should be getting destroyed ahead of time by the VB6 GC.

        Bob O`Bob
--
posting from work, but representing only myself



Sun, 12 Sep 2004 10:37:19 GMT  
 Obscure bug finally found
Interesting for a database programmer.  We can't call functions
like
    Array(RecordSetObject.field(1),RecordSetObject.field(2))
because VB internal functions get a reference to the object
which will never be properly released (the process has to be
killed because it won't close properly)

(david)

Quote:

> I'm new to this group, but I thought I'd post a problem I just found in one
> of my projects.  I've been trying to hunt down this particular bug for
> weeks.

> My project is in VB5, and after compiling and testing it out, it would
> always crash.  The problem was though it crashed randomly, sometimes after
> running for a few minutes, sometimes several hours (with the same load).
> Sometimes it would simply crash to the desktop with no error message at all,
> sometimes with an "Access Violation", sometimes with "Stack Fault", and
> sometimes even with "Illegal Procedure Call".

> I put in tons of debug code, was writing to a text file every time I entered
> and left every function.  I found it was crashing randomly in different
> functions, and I was unable to track it down to any particular function.

> Anyhow, I've been coding in VB for 11 years (since v1.0), and this was very
> frustrating.  Add to that if I compiled the code in "P-Code" my project
> worked flawlessly!  But I found it.  One of my functions requires an array
> as an argument, easy right?  Well, I thought I'd save a step in creating the
> array before I passed it and just create it *as* I pass it:

>     Call SomeFunction(Array("one","two","three"))

> instead of:

>     aArray = Array("one","two","three")
>     Call SomeFunction(aArray)

> I'm hoping someone here can confirm what I think was/is happening.  VB5
> passes all parameters by reference by default.  Normally of course this
> isn't a problem.  But when I was passing  Array("one","two","three") as an
> argument, VB was creating a temporary reference for the result.  I don't
> know if it was pushed onto the stack, or put in memory somewhere, but it was
> probably marked somehow as "temporary" with an unknown lifespan.  I'm
> assuming that during normal VB memory/stack "garbage collection" it was
> being destroyed, and causing major problems even if the reference wasn't in
> use anymore.  I also assume that this "garbage collection" was the reason
> why the program was sometimes running for minutes and sometimes hours before
> crashing.  When the program was compiled in "P-Code", I think VB handles all
> variables and parameters a little different, and thus my program didn't
> crash.

> Now that I've removed using "Array()" as a parameter I'm passing, the
> program works flawlessly compiled to "native code".  Sorry for the long
> post, but I'm hoping to spare someone else the pain I went through in
> tracking this problem down.  I'm also hoping to get some help from someone
> knowledgeable in the internals of VB to explain why this was happening, and
> if my assumptions are correct.

> Thanks,
> S. Murray




Mon, 13 Sep 2004 20:22:13 GMT  
 Obscure bug finally found

Quote:
> Interesting for a database programmer.  We can't call functions
> like
>     Array(RecordSetObject.field(1),RecordSetObject.field(2))
> because VB internal functions get a reference to the object
> which will never be properly released (the process has to be
> killed because it won't close properly)

Use Array(RecordSetObject(1).Value,RecordSetObject(2).Value)
instead?  Or do you want an array of Field object references?

--
Joe Foster <mailto:jlfoster%40znet.com>  Wanna buy a Bridge? <http://xenu.net/>
WARNING: I cannot be held responsible for the above        They're   coming  to
because  my cats have  apparently  learned to type.        take me away, ha ha!



Mon, 13 Sep 2004 00:45:33 GMT  
 
 [ 4 post ] 

 Relevant Pages 

1. VS 2003, Bug finally found?

2. Reserved Words in an Enumerated Data Type [NB Possible obscure bug noted]

3. Obscure bug: Query only works when debugging

4. BUG: data control refresh (obscure)

5. SCARY bug or obscure feature

6. Obscure Error Message - Invalid Code:D=Found on Line:1

7. MAJOR Try...Catch...Finally BUG!

8. finally found something that actulaly works

9. Finally found a Title Bar Gradient OCX

10. I 'VE FINALLY FIND!!!!!!!!!

11. finally found something that actulaly works

12. Obscured Text In a Cell

 

 
Powered by phpBB® Forum Software