How to set Heaptrc in linux

[TRon]

so, n-th posts further along and we finally arrive at the culprit as could have been seen from the first dump that i posted: heaptrace (or the data it relies on) is borked for x86_64-linux.

Would be interesting to see how this discussion progresses. As a wild guess: very sloooow 

[Thaddy]

This should also be the case on Linux, otherwise there is a bug. (or a setup problem)

[af0815]

Now I see.

Can you set in Project options the level of optimazion to 0 = No optimazion for debugging. It looks like the callstack for heaptrace is in Linux shorter.

I work every day with heaptrace, but if i see the first lines in a leak, i know normaly where my fault is, so did not see it is shorten on Linux (got blind at work)

[TRon]

Can you set in Project options the level of optimazion to 0 = No optimazion for debugging. It looks like the callstack for heaptrace is in Linux shorter.

If you got the log from my post then you are effectively looking at the output from no optimization on whatsoever.

edit: lpi

Code: [Select]

<?xml version="1.0" encoding="UTF-8"?>
<CONFIG>
  <ProjectOptions>
    <Version Value="12"/>
    <General>
      <SessionStorage Value="InProjectDir"/>
      <Title Value="project1"/>
      <Scaled Value="True"/>
      <ResourceType Value="res"/>
      <UseXPManifest Value="True"/>
      <XPManifest>
        <DpiAware Value="True"/>
      </XPManifest>
      <Icon Value="0"/>
    </General>
    <BuildModes>
      <Item Name="Default" Default="True"/>
    </BuildModes>
    <PublishOptions>
      <Version Value="2"/>
      <UseFileFilters Value="True"/>
    </PublishOptions>
    <RunParams>
      <FormatVersion Value="2"/>
    </RunParams>
    <RequiredPackages>
      <Item>
        <PackageName Value="LCL"/>
      </Item>
    </RequiredPackages>
    <Units>
      <Unit>
        <Filename Value="project1.lpr"/>
        <IsPartOfProject Value="True"/>
      </Unit>
      <Unit>
        <Filename Value="unit1.pas"/>
        <IsPartOfProject Value="True"/>
        <ComponentName Value="Form1"/>
        <ResourceBaseClass Value="Form"/>
        <UnitName Value="Unit1"/>
      </Unit>
    </Units>
  </ProjectOptions>
  <CompilerOptions>
    <Version Value="11"/>
    <Target>
      <Filename Value="project1"/>
    </Target>
    <SearchPaths>
      <IncludeFiles Value="$(ProjOutDir)"/>
      <UnitOutputDirectory Value="lib/$(TargetCPU)-$(TargetOS)"/>
    </SearchPaths>
    <CodeGeneration>
      <Optimizations>
        <OptimizationLevel Value="0"/>
      </Optimizations>
    </CodeGeneration>
    <Linking>
      <Debugging>
        <UseHeaptrc Value="True"/>
      </Debugging>
      <Options>
        <Win32>
          <GraphicApplication Value="True"/>
        </Win32>
      </Options>
    </Linking>
  </CompilerOptions>
  <Debugging>
    <Exceptions>
      <Item>
        <Name Value="EAbort"/>
      </Item>
      <Item>
        <Name Value="ECodetoolError"/>
      </Item>
      <Item>
        <Name Value="EFOpenError"/>
      </Item>
    </Exceptions>
  </Debugging>
</CONFIG>


[dbannon]

Please go back and re read Blaazen's post, heaptrace on linux reports what calls the function or procedure where the leak happens.  In this case -

$0000000000450BE7  DOCREATE,  line 921 of include/customform.inc

That tells you its happening in a create form function. Sure its not great but it does tell you its happening and tells you to look in the create function of one of your forms. Its usually not that hard to look at the most recently changed formcreate() and there it is !

Davo

 

[TRon]

@dbannon:
I /lnow/ how to interpret the output from heaptrace. That is not the problem.

If you are truly of the opinion that this is how a trace is suppose to look like then that is fine but then using heaptrace for finding leaks is useless for me and for every other common user of Lazarus (let alone newbies or advising newbies to use heaptrace).

It is simply borked, and if that output is actually what should be outputted then it is broken by design (not to add completely useless for real world situations).

[dbannon]

No, I am quite sure thats not how it is supposed to look, but it is how it does look ! Either fix it or get used to it.

If the leak in in the 'main' function, bad luck ! Or a method called directly by LCL. But in most cases of a leak, its in a method that has been called from your own code, and therefore the report is far easy to read.

It is simply borked, and if that output is actually what should be outputted then it is broken by design (not to add completely useless for real world situations).

Rubbish. As I said, its not great but it is usually quite functional. I have been using it like that for years, and I have written a lot of leaky code ! But I never failed to find the leak. I always assumed every one only saw the calling method. Quite surprised that windows user get more specific information, good for them !

Here is a simple rule to avoid this problem, when you write leaky code, make sure its in a function or procedure that is called by your own code !  Easy...

Davo

[marcov]

NOte that if the topline is missing, your code is possibly compiled with optimization on that turns off stackframes for leaf procedures/methods ?