-3

I've been working on a money management program in freepascal for quite some time and recently started to use pointers to resolve some limitations. It works fine 90% of the time. I'm trying to debug an EAccessViolation that seem to happen at random times. I checked every pointer, everywhere it's been allocated, accessed or freed, it all looks fine to me.

I've finally found a situation where it always happen and tracked down the part of the code "responsible" : a fonction that builds an ansistring that's supposed to be about 2000 chars long. I replaced it by a pchar and realised the access violation occurs when i try to allocate more than 524 char with stralloc. I can allocate as many pchar as I want as long as they're under 524 chars.

If someone has any idea how i can get an access violation without trying to read/write anything, that would be great. It's been pointed out to me THIS IS a heap corruption

I also tried to run my program on a different version of my OS (ubuntu 10, lubuntu 14) on the same computer, same problem. But using another computer, on lubuntu 14, it seems to work fine. With a few more tests I've found out that the problem occurs whatever OS or computer I use, but doesn't happen if the size of the terminal I run the program into is greater than a certain value. There might be a problem with my use of the CRT unit and more specifically the "window" function even though I don't use any pointers in my unit accessing the CRT's functions? I'm looking into it...

could it be a faulty memory ? memtest86 returned no errors ... NO

thanks for any suggestions.

paiiburn
  • 1
  • 2
  • 1
    From the [help/on-topic]: *Questions seeking debugging help ("why isn't this code working?") must include the desired behavior, a specific problem or error and the shortest code necessary to reproduce it in the question itself. Questions without a clear problem statement are not useful to other readers. See: [How to create a Minimal, Complete, and Verifiable example](http://stackoverflow.com/help/mcve).* – Ken White Jun 21 '16 at 02:41
  • 1
    You think it likely that the hardware is at fault? You need to have more self-doubt. Cultivate an attitude of scepticism of your own abilities. Problem is in your code. Only you can see it. Good luck. – David Heffernan Jun 21 '16 at 05:39
  • @Ken White, I feel it is a specific problem, maybe I didn't explain it well enough. I didn't include code because, from what I understand, the origin of access violations errors can be anywhere in the program (pointers unitialized, accessed after being freed,...) not necessarily the part of the code that's being executed at the moment the violation occurs, and my program is over 5000 lines in several units. My question was, how is it possible to generate an access violation with this code : `p:=stralloc(2000);` ; p being a pchar, and stralloc the function from freepascal rtl's strings unit. – paiiburn Jun 21 '16 at 06:55
  • @DavidHeffernan, I actually don't think it's a faulty memory, thanks for confirming it. It's was just a stupid question, because I'm out of ideas. Believe me, I have self doubt, I've had quite a few access violations errors in this program, but they were always happening while trying to access a freed or out of boundary pointer, or releasing memory already freed. I don't understand how it's possible to have an access violation while just trying to allocate memory ! Thanks. – paiiburn Jun 21 '16 at 07:19
  • That is very common. A defect elsewhere corrupts the heap but the failure then occurs when performing later allocation. You clearly have heap corruption. You will need to do some debugging. Quite why you want to perform manual allocation is beyond me. Why are you shunning the native string type? – David Heffernan Jun 21 '16 at 07:22
  • @DavidHeffernan, I actually don't use pchar, I just replaced my ansistring by a pchar to see if the violation occured while the memory allocation was performed, and it does. The problem also occurs with the ansistring. What I don't understand is : isn't the memory supposed to be free, shouldn't the stralloc function or the equivalent mechanism for growing an ansistring be aware of memory it can use? Thanks. – paiiburn Jun 21 '16 at 07:49
  • You. Have. Corrupted. The. Heap. – David Heffernan Jun 21 '16 at 07:53
  • @DavidHeffernan, I'm sure you're right. I guess I just don't understand what it really means. Thanks anyway. – paiiburn Jun 21 '16 at 07:57
  • You have written to memory addresses that you have not allocated. For instance a buffer overrun. That in turn has corrupted the structures used by the heap to manage allocation. Once the heap is corrupt, it is possible for future allocations or deallocations to fail. You need to debug this. Since you are on Linux you can use Valgrind which will locate the error in your program. – David Heffernan Jun 21 '16 at 08:02
  • Also, if somebody explains your problem with terminology you don't understand, don't be helpless. Do a web search and learn. It will be far better for you to become more self-sufficient, able to learn by yourself rather than relying on individuals. You'll get far more from reading around the topic of heap corruption than you will from a short comment here. – David Heffernan Jun 21 '16 at 08:05
  • @DavidHeffernan, Oh thanks a lot, I didn't think it was possible to have a buffer overrun without having an access violation at that moment. I already tried to use valgrind (using --leak-check=yes ; and -gl while compiling) but it showed no other problem prior to that string's allocation. – paiiburn Jun 21 '16 at 08:10
  • Access violation during heap allocation/deallocation is due to heap corruption with probability > 0.999. Now to debug your program. Nothing more that we can do. – David Heffernan Jun 21 '16 at 08:23
  • @DavidHeffernan, thanks again for taking the time to explain my problem. I think i have a better understanding of what I'm looking for now. This will be very helpfull during the long hours I'll spend reviewing my code, so thanks a lot. – paiiburn Jun 21 '16 at 09:13

1 Answers1

1

Base Free Pascal debug procedure for elusive problems:

  • enable all runtime checks with -CRriot
  • Poison local variables with -gtt ( you might see a different number of t's in other sources, that just changes the pattern)
  • (if it compiles on Linux, FreeBSD), compile with -gv and run it through valgrind

And no, probably it is just a programming error.

Marco van de Voort
  • 25,628
  • 5
  • 56
  • 89