Board index » delphi » AV in docking code when not docking????

AV in docking code when not docking????

We have encountered a "mystery" AV which reproduces itself in a number of
our Apps.
It happens when switching between Apps, or when servers launch themselves -
somehow related to activation of the main form of the app, possibly...
It appears as an AV when reading a low address - sometimes 000000

In tracking through the MAP file it appears it may be related to the
TControl.DockManual method.
However we arent using docking at all in our apps
Has anyone come across anything even remotely similar ?

Regards

Tim

 

Re:AV in docking code when not docking????


You should try running your applications through a debugging tool, like
Sleuth QA, or Memproof.  Memproof has the advantage of being free, although
it's not as fully featured.

Chances are it's a memory overwrite somewhere or a third party component you
use.

Matt.

Quote
"Tim Jarvis" <t...@no.spam.for.me> wrote in message news:3952c7ef@dnews...
> We have encountered a "mystery" AV which reproduces itself in a number of
> our Apps.
> It happens when switching between Apps, or when servers launch
themselves -
> somehow related to activation of the main form of the app, possibly...
> It appears as an AV when reading a low address - sometimes 000000

> In tracking through the MAP file it appears it may be related to the
> TControl.DockManual method.
> However we arent using docking at all in our apps

> Has anyone come across anything even remotely similar ?

> Regards

> Tim

Re:AV in docking code when not docking????


Not a bad idea, athough not using any 3rd party components in this app (It's
a Server app, communicating via Borland's socket server).

Could be a memory overwrite as you say, but as indicated before, it appears
to occurring in TControl docking code. But I could not categorically say
that. One thing for sure I can not get it to stop in the integrated
de{*word*81}.

Rgds Tim

Quote
Matt P <Matt.Pal...@Zygon.com> wrote in message news:3953914c@dnews...
> You should try running your applications through a debugging tool, like
> Sleuth QA, or Memproof.  Memproof has the advantage of being free,
although
> it's not as fully featured.

> Chances are it's a memory overwrite somewhere or a third party component
you
> use.

> Matt.

> "Tim Jarvis" <t...@no.spam.for.me> wrote in message news:3952c7ef@dnews...
> > We have encountered a "mystery" AV which reproduces itself in a number
of
> > our Apps.
> > It happens when switching between Apps, or when servers launch
> themselves -
> > somehow related to activation of the main form of the app, possibly...
> > It appears as an AV when reading a low address - sometimes 000000

> > In tracking through the MAP file it appears it may be related to the
> > TControl.DockManual method.
> > However we arent using docking at all in our apps

> > Has anyone come across anything even remotely similar ?

> > Regards

> > Tim

Re:AV in docking code when not docking????


Yes.  I've had problems like this.   Without debug info - failure, with
debug info - no failure.  Of course, this still points to some sort of
memory problem - adding the debug info when compiling the code simply moves
the code around a bit, often preventing the symptoms from occuring in the
first place.  It doesn't cure the problem - it can merely make it less
visible.

--
Regards,

Matt Palmer
Author of mpDockManager
http://freespace.{*word*269}.net/matt.palmer/

Re:AV in docking code when not docking????


SOmething else you might consider, let's say that you overrwrote some memory so
that you end up doing a JMP to the wrong address (correct address overwritten)
and so then, you THINK the problem is related to the TControl, but in fact, it
has NOTHING to do with it :) Please don't forget about that type of scenerio. A
thing "I LIKE" to do to try to determine if that sort of thing is happening is
to step thru the call back stack, or if you are not familiar with assembler
code, then a less better method would be that you could take note as to the
address in TControl where it blows. Then run it 3 times and see if it blows in
the SAME address spot. THEN turn toggle your "Check for overflow" and "Range
checking". So, if they were on, turn them off, and vice versa. This will make
your resulting code a DIFFERENT size, and by doing that if you end up blowing up
at the same address, then it's a good bet (75%) that your problem wasn't caused
by an invalid jump into the TControl logic.

Davie

Quote
Tim Jarvis wrote:
> Not a bad idea, athough not using any 3rd party components in this app (It's
> a Server app, communicating via Borland's socket server).

> Could be a memory overwrite as you say, but as indicated before, it appears
> to occurring in TControl docking code. But I could not categorically say
> that. One thing for sure I can not get it to stop in the integrated
> de{*word*81}.

> Rgds Tim

> Matt P <Matt.Pal...@Zygon.com> wrote in message news:3953914c@dnews...
> > You should try running your applications through a debugging tool, like
> > Sleuth QA, or Memproof.  Memproof has the advantage of being free,
> although
> > it's not as fully featured.

> > Chances are it's a memory overwrite somewhere or a third party component
> you
> > use.

> > Matt.

> > "Tim Jarvis" <t...@no.spam.for.me> wrote in message news:3952c7ef@dnews...
> > > We have encountered a "mystery" AV which reproduces itself in a number
> of
> > > our Apps.
> > > It happens when switching between Apps, or when servers launch
> > themselves -
> > > somehow related to activation of the main form of the app, possibly...
> > > It appears as an AV when reading a low address - sometimes 000000

> > > In tracking through the MAP file it appears it may be related to the
> > > TControl.DockManual method.
> > > However we arent using docking at all in our apps

> > > Has anyone come across anything even remotely similar ?

> > > Regards

> > > Tim

Re:AV in docking code when not docking????


YEs, and so in those situations, what I normally do is this. I leave all the
compiler options set in order to make the program blow. Then, I add (sprinkle)
a bunch of writelns statements in my code so I can see about what point the
whole thing blows. Then it sort of gives me a clue as to what's going on.

Davie

Quote
Matt P wrote:
> Yes.  I've had problems like this.   Without debug info - failure, with
> debug info - no failure.  Of course, this still points to some sort of
> memory problem - adding the debug info when compiling the code simply moves
> the code around a bit, often preventing the symptoms from occuring in the
> first place.  It doesn't cure the problem - it can merely make it less
> visible.

> --
> Regards,

> Matt Palmer
> Author of mpDockManager
> http://freespace.{*word*269}.net/matt.palmer/

Re:AV in docking code when not docking????


Quote
> to step thru the call back stack, or if you are not familiar with

assembler

Problem is, no call stack when AV'ing, it's not stopping in the IDE.

Quote
> the SAME address spot. THEN turn toggle your "Check for overflow" and
"Range
> checking". So, if they were on, turn them off, and vice versa. This will

make
Good idea, but the problem is intermittent and not reproducible. It's also
happening in all of the applets (the app consists of separate client apps
that are launched by a launcher app) it seems that it happens only when one
app loses focus to another.

Rgds Tim.

Re:AV in docking code when not docking????


Sprinkle some writeln statements. For example, let's say in the form.create
method you put 2 writelns. 1 at the start and 1 at the end of the function.
Then do the same for the form.onshow event and onactivate ect... Also, as part
of the writeln indicate the name of the app so that when you get a bunch of
display stuff, you know which app made the statements. THen hopefully if you
get a scenerio like this:

entered app1 create
exited app1 create
entered app1 show
exited app1 show
entered app1 activate
AV BLOW UP

Then you know that the problem occured in the OnActivate. Get the idea?

Davie

Quote
Tim Jarvis wrote:
> > to step thru the call back stack, or if you are not familiar with
> assembler

> Problem is, no call stack when AV'ing, it's not stopping in the IDE.

> > the SAME address spot. THEN turn toggle your "Check for overflow" and
> "Range
> > checking". So, if they were on, turn them off, and vice versa. This will
> make

> Good idea, but the problem is intermittent and not reproducible. It's also
> happening in all of the applets (the app consists of separate client apps
> that are launched by a launcher app) it seems that it happens only when one
> app loses focus to another.

> Rgds Tim.

Re:AV in docking code when not docking????


Yeah, spose it can't hurt to try. At least that give an avenue to try.

Rgds Tim.

Quote
> Then do the same for the form.onshow event and onactivate ect... Also, as
part
> of the writeln indicate the name of the app so that when you get a bunch

of

Other Threads