ansaurus

Question

Answer 1

+4 A:

I strongly suspect that the TDeviceModule reference involved is invalid. You won't always see any ill effects of calling a method on a bad object reference until some way into the method body unless the method is virtual in which case the invocation of the method itself will typically (always?) yield an AV.

Deltics 2010-06-21 02:39:53

+1 That's IMHO the most likely one too, without examining in detail.

Marco van de Voort 2010-06-21 06:50:22

i logged the initial pointer values for those objects when it worked and compared Self just before it executed Begin and it was the same value.

X-Ray 2010-06-21 18:38:51

i also tried "exercising" the stack before making the call where the error occurs: i:=0; while i<100000 do begin asm push 00 end; inc(i); end; i:=0; while i<100000 do begin asm pop ecx end; inc(i); end;i can do that *right* *before* making the call where the error occurs without a problem! i think i'm about to learn something important...thank you all for your help!

X-Ray 2010-06-21 18:41:14

I'm not quite sure what you are saying w.r.t logging initial pointer values and then comparing to "self", but *any* value of self can be a bad reference, even if that same value was previously a *good* reference. If the object referenced has been free'd but you still have a variable containing that reference it will have the same value as *before* it was free'd, but it now references unallocated memory (or worse, memory that has since been re-allocated to some other object).

Deltics 2010-06-21 21:24:11

thank you Deltics--got it figured out (see my newest answer).

X-Ray 2010-06-21 22:54:56

I don't think it's the case. If Self is invalid - how possible can it affect "push 0" instruction?

Alexander 2010-06-22 11:25:23

@Alexander - To be honest I wasn't looking at the ASM. The Pascal code as posted didn't contain anything that pointed to potential stack fault and the fact that an AV occurred rather than an actual stack exception suggested to me that the problem might lie in the use of the reference to the instance rather than the method implementation itself. It transpires that the code posted wasn't complete, but I think/hope that my suggestion at least helped eliminate one possible explanation and thus help narrow the list of suspects and assist in the resolution.

Deltics 2010-06-22 21:09:26

Answer 2

+2 A:

I'd comment out each of the 3 variables, then un-comment one at a time to see if any particular one of them is blowing up. If so, you've just cut your problem by 2/3.

Chris Thornton 2010-06-21 03:00:53

Answer 3

+3 A:

From your comment ("error happens here") your error pops up in the loop that sets up stack space, all 212 Kb of it! It has absolutely nothing to do with the parameters you're passing to the procedure and nothing to do with the viability of the object you're passing as a parameter (there's no CALL over there, it's just an JNZ that loops to the PUSH $00 thing until the DEC ECX operation marks the ZERO flag, that is, $1a9e9 times).

Since you're dealing with a procedure that uses 212Kb of stack space maybe you should try increasing the stack space by a lot more! Even better, figure out why your procedure is using up that much space and figure out if other procedures are in the same situation (look out for large Records used as local variables).

Cosmin Prund 2010-06-21 05:44:14

good point; more about this in the answer i'm adding.

X-Ray 2010-06-21 22:18:38

Answer 4

+3 A:

See this question: http://stackoverflow.com/questions/765162/guard-page-exceptions-in-delphi

Normally, you should get stack overflow exception, when you're running out of your stack. But if your guard page was touched by someone else and exception was eaten silently without expanding stack - then your code will crash with AV when you will expand your stack.

This isexactly what happening in your code: you expand stack and you got the AV. This assembler cycle is designed to touch stack to trigger stack expansion by guard page. Since guarg page is gone, but stack was not expanded - you got simple AV here.

Note, that increasing stack size will not help, since stack doesn't grow at all.

You need to find who plays with your stack.

Alexander 2010-06-21 07:39:05

Answer 5

A:

One possibility would be that the 3 local variables (stack variables) are growing larger than expected. I suppose this could happen if the objects are declared in a unit that is contained in another BPL and it's not rebuilt correctly (i.e. your program thinks it's smaller than it really is).
Whatever the reason, you can experiment and find out if that's happening. Place "buffer" variables between and after your 3 vars.

ex: 
  var 
    selChannel:TDeviceChannel; 
    Buff1 : array[1..1024] of AnsiChar;
    det:TDeviceDetector; 
    Buff2 : array[1..1024] of AnsiChar;
    shoKVMeas:TStoMeasurement; 
    Buff3 : array[1..1024] of AnsiChar;

This should do two things for you. 1) it should prevent the A/V, assuming that 1024 is enough. 2) by examining the arrays, you should be able to see if garbage appears. That would indicate that they're being overwritten by the declaration directly above.

Chris Thornton 2010-06-21 12:45:28

Answer 6

A:

here's what i learned:

by exercising the object, i found it was healthy.

by dumping stuff on the stack i determined it really was running out of stack space.

procedure TDeviceModule.Validate;
const
  icTestSize=400000;
var
  i:integer;
begin
  // ask the object stuff to try to see if it's healthy

  SelectChannel(dcCh1);

  ClassName;

  for eChannelNum:=low(TDeviceChannelNum) to high(TDeviceChannelNum) do
    if HasChannel(eChannelNum) then
      m_aChannels[eChannelNum].Validate;

  // exercise the stack to see if loading on extra stuff is a problem...it is

  i:=0;
  while i<icTestSize do
    begin
      asm
        push 00
      end;
      inc(i);
    end;

  i:=0;
  while i<icTestSize do
    begin
      asm
        pop ecx
      end;
      inc(i);
    end;
end;

there were a few nested functions (neither it's use nor it's declaration were part of the question because i didn't realize how much they were a part of the problem) who returned a record i'll call TBigRecord...it is 32 KB. not just that but it was used quite a few times.

procedure TDeviceModule.GetMeasurements(blah blah blah);

  function _DoSomething1(blah blah blah):TBigRecord;
  begin
  end;

  function _DoSomething2(blah blah blah):TBigRecord;
  begin
  end;

  function _DoSomething3(blah blah blah):TBigRecord;
  begin
  end;

begin
  _DoSomething1(blah blah blah);
  _DoSomething2(blah blah blah);
  _DoSomething3(blah blah blah);
end;

each time i use it (and even if i don't use the result), i get stack space allocated for the result value.

the solution i used for now was to change those functions to procedures since i wasn't using the return value anyway.

i had increased the stack space but not enough to prevent this problem.

can i expect stack overflow to be reported in such a case?

thank you all for your valuable assistance! this problem had me worried...

X-Ray 2010-06-21 22:53:28

I think you see something else. First: running out of stack space means stack overflow, not AV. Second: use a tool or code to examine ESP/Current stack size and top of the stack for your thread. It's very likely that your stack is far from reaching its maximum. Third: changing function to procedure doesn't really solve anything, it can only hide something. That's because function ABC(): TSomeRecord is actualy a procedure ABC(var Result: TSomeRecord) on binary level.

Alexander 2010-06-22 11:32:13

yes; i would've expected to see a Stack Overflow error instead of AV. what tool do you suggest for studying this more? i am somewhat concerned that this was a problem (even if the problem has been "solved")...can't help but wonder if i shall hear from this problem again.i wasn't using the return value so i removed it entirely.thank you for your help!

X-Ray 2010-06-22 14:30:43

Take a look at VMMap or similar tools.

Alexander 2010-06-22 15:21:43

Answer 7

A:

Sorry to be simplistic but...

_DisplayList:TMeasDisplayListAncestor AND _DisplayList: TObjectList are both in scope simultaneously.

So are two eExposureStatus of differing types and two bActiveErrorEnabled of Boolean.

when you call _GetMeasurement(ExpInfo, _DisplayList, eChannelNum, eExposureStatus, ctdVal1) in the local procedure which variable and Type is it using? TobjectList or TTMeasDisplayListAncestor ?

Unless I'm just more drunk than I think... :)

Despatcher 2010-06-21 23:15:12

i don't see TMeasDisplayListAncestor and TObjectList used for the same object anywhere.i'm ok about the two eExposureStatus of differing types and the overlapping variable names bActiveErrorEnabled._DisplayList is a descendant of TTMeasDisplayListAncestor.

X-Ray 2010-06-22 14:23:10

ansaurus

tags:

views:

answers:

interesting stack problem?

related questions