Fatal: Internal error 2012010601

[joho]

What does "Fatal: Internal error 2012010601" mean?

[marcov]

Something heaptrc related (-gh)

Code: Pascal  [Select][+][-]

1.          if (cs_use_heaptrc in current_settings.globalswitches) and
2.             (cs_checkpointer in current_settings.localswitches) and
3.             not(cs_compilesystem in current_settings.moduleswitches) and
4.             tpointerdef(left.resultdef).compatible_with_pointerdef_size(tpointerdef(voidpointertype)) and
5.             not(nf_no_checkpointer in flags) and
6.             { can be NR_NO in case of LOC_CONSTANT }
7.             (location.reference.base<>NR_NO) then
8.           begin
9.             if not searchsym_in_named_module('HEAPTRC','CHECKPOINTER',sym,st) or
10.                (sym.typ<>procsym) then
11.               internalerror(2012010601);
12.             pd:=tprocdef(tprocsym(sym).ProcdefList[0]);
13.             paraloc1.init;
14.             paramanager.getintparaloc(current_asmdata.CurrAsmList,pd,1,paraloc1);
15.             hlcg.a_loadaddr_ref_cgpara(current_asmdata.CurrAsmList,left.resultdef,location.reference,paraloc1);
16.             paramanager.freecgpara(current_asmdata.CurrAsmList,paraloc1);
17.             paraloc1.done;
18.             hlcg.allocallcpuregisters(current_asmdata.CurrAsmList);
19.             hlcg.a_call_name(current_asmdata.CurrAsmList,pd,'FPC_CHECKPOINTER',[@paraloc1],nil,false);
20.             hlcg.deallocallcpuregisters(current_asmdata.CurrAsmList);
21.             include(current_settings.moduleswitches,cs_checkpointer_called);
22.           end;
23.       end;
24.  

So either checkpointer is not defined for the current architecture, or it is called on a symbol that is not a procedure?

[joho]

Thanks!

Hmm ... I was getting it as some really weird places in the source, like:

function foo (parms) :boolean;
begin
  writeln ('Not implemented');
  abort;
end;

I'm wondering if that was actually the place it went tits up, or if the problem began much earlier (like pointer corruption or something). But just to be clear, I got this during compile time.

[engkin]

LOL, do you have a unit named heaptrc?  ;-O
If yes, then please change its name. You confused the compiler. 

1^st Edit:
To be precise, if you have {$CheckPointer on} and you use pointers and name one of your units heaptrc this will produce internal error 2012010601.

2^nd Edit:
Sample project attached.

[joho]

LOL, do you have a unit named heaptrc?  ;-O
If yes, then please change its name. You confused the compiler. 

1^st Edit:
To be precise, if you have {$CheckPointer on} and you use pointers and name one of your units heaptrc this will produce internal error 2012010601.

2^nd Edit:
Sample project attached.

Uhm, no I do not have such a unit And it's "sort of" strange that it would always "crash" on that precise place (IMHO).

[engkin]

How about compiling with -va
Save the output messages to a file
Zip it and share it with us if possible.

[joho]

I'll try to remember that the next time it barfs. It doesn't do it every time.

[JernejL]

I gotten to trigger this when trying to use heaptrace unit in my program.
 
It crashes with this error on line:
 

Code: Pascal  [Select][+][-]

1.  
2. TWorldRaycastResults = packed record
3.  
4.         newtonWorld: PNewtonWorld;
5.  
6.                 PtOrigin,
7.                 PtTarget,
8.         PtCenterAABB: Vector;
9.  
10.                 HitDistance: single;
11.                 HitCoordinates: Vector;
12.                 hitNormal: Vector;
13.                 HitAnything: boolean;
14.  
15.                 NearestBodyHit: PNewtonBody;
16.                 FirstBodyHitUserData: pointer;
17.         FaceID: int64;
18.                 FartherstBodyHit: PNewtonBody;
19.  
20.         AllBodies: array of PNewtonBody;
21.  
22.                 WhenToStop: integer;
23.                 hitcallback: NewtonBodyIteratorEx;
24.         ListAllBodies: boolean;
25.  
26.                 FilterData: Pointer;
27.                 FilterMethod: TNfilter;
28.                 FilterData2: Pointer;
29.                 FilterMethod2: TNfilter;
30.  
31.         end;
32.  
33. PWorldRaycastResults = ^TWorldRaycastResults;
34.  
35. function filter_procedure_explosion(const body: PNewtonBody; const userData: pointer; const RayCastResults: pointer): Integer; cdecl;
36. var
37.         TmpMatrix: TMatrix4f;
38.     contact_coord, normal_coord: Vector;
39.         explosion_radius, distance_to_explosion_origin: Single;
40.         classpointer: Pointer;
41.     wcr: PWorldRaycastResults;
42. begin
43.  
44.         //assert(PWorldRaycastResults(RayCastResults).FilterData = body, 'filter_procedure_explosion problem with data.');
45.  
46.         wcr:= PWorldRaycastResults(RayCastResults);
47.  
48.         if wcr.FilterData = body then exit(0); <- crash on this line, where i do a simple pointer comparison
49.        
50. ..
51.  
52. end;
53.  
54.  

I have no idea why this happens, it's a pointer comparison on the line - it could be a bug in how heaptrc is implemented.
 
compiled in {$mode delphi} 
 

[JernejL]

I get this errot to happen on more places if i comment that out, it is nearly always when casting a pointer to pointer type (Psomethingtype^), i suspect a flaw in how freepascal handles this in mode delphi?
 
Edit: could be related to https://bugs.freepascal.org/view.php?id=29899 - i might need a compiler upgrade? (using 3.0.4)
 

[PascalDragon]

Yes, you'll need to wait for 3.2 (or compile a patched release compiler yourself).

[JernejL]

I tried 3.2.0 and the error still occurs.
 
Newton_ext.pas(1344,17) Error: Internal error 2012010601
 
Looks like i'll have to reopen the ticket.
 

[PascalDragon]

In that case please provide a small, self contained example that demonstrates this.

[jamie]

I've been able to blow up the HEAPTRC myself during execution of some code but that was caused by me flooding memory (spilling over) where I disrupted the handling of HeapTrc.

 How the compiler itself comes into play with this is strange but is it possible there is mistakenly another "InternalError" of the same number being generated elsewhere ?

 Seems like I remember seeing this once reported where as the same number being used in two different places unrelated to each other..

[PascalDragon]

I've been able to blow up the HEAPTRC myself during execution of some code but that was caused by me flooding memory (spilling over) where I disrupted the handling of HeapTrc.

 How the compiler itself comes into play with this is strange but is it possible there is mistakenly another "InternalError" of the same number being generated elsewhere ?

 Seems like I remember seeing this once reported where as the same number being used in two different places unrelated to each other..

You just need to search the compiler's source code for the number to see whether it occurs multiple times (hint: this one doesn't). And this internalerror can only trigger if both -gh and -gc (or $CheckPointer On) is given, cause the compiler looks for the CheckPointer function in unit heaptrc.

[Thaddy]

It is very easy to blow up heaptrc (not heaptrace) if you install an alternative memory manager.
That said: an internal error should be fixed.

The ratio is that heaptrc is a memory manager by itself. Don't ever use things like cmem and the likes together with heaptrc.