I've been working on a Turbo C program for a while now. I had my usual share of bugs and fixes, until it got a really weird error -- an error that could only be explained by something accidentally overwriting memory.

It starts by reading in a file, and transferring most of what it reads into linked-list heap storage. But when the input file got big enough, the program died.

I went through much work and many tears before I found out what went wrong. I fixed it, then I decided to post my story on the Stack Overflow site, to see if others could figure it out.

I gave them a clue -- I said the answer is on your monitor right now. But the voters there made the mods take it down because they said it was on the wrong site -- Stack Overflow is not for puzzles.

I say it was on the right site, and even though it was a puzzle of sorts, it had to be there. It wasn't like it was PCG or anything like that.

So here is the puzzle: what went wrong with the program, and why was that the right site?

If no one gets it within 24 hours, I will post an additional clue.

  • 2
    For the record, Stack Overflow does not exist for the sake of making jokes or pointing out silly coincidences. It is meant to provide a space for people to post their real issues and get real help. If you were initially unaware of the problem, it would have been a legitimate post, even if you later went back and self-answered what the solution was and how you came to it. The voters there did precisely what they are meant to do and removed a post that I imagine contributed nothing meaningful or new. – feelinferrety Oct 13 '17 at 18:57
  • actually it isn't and wasn't – Jasen Oct 13 '17 at 20:08
up vote 4 down vote accepted

Beacause of a:

Stack overflow :P

The issue with your implementation is the overhead of a linked list. While every program needs it's own space to run, you improperly allocated storage space for your linked list to live, and you ended up with a

Stack overflow

While a linked list is not altogether bad, it is almost analogous to claiming contiguous space in certain circumstances. You are telling the OS that you need the entire file as part of your working set, instead of logically chunking the data apart.

  • Now you guys know why I wanted to post this in the stack overflow site. But the people there had no sense of humor or challenge. – Jennifer Oct 13 '17 at 14:46
  • 1
    Some more on what actually happened: Turbo C has memory models, and I was using the Small memory model, where the data segment has static variables at the bottom, the heap just above that, with the stack at the top and growing down. When you allocate heap storage, Turbo C checks to see there are at least 256 bytes left between the top of the heap and the bottom of the stack. With a complex program like I created, wit functions calling functions calling functions calling functions, I needed much more than that. Adding the -N compile time option (check for stack overflow) fixed that. – Jennifer Oct 13 '17 at 14:50
  • I read in the entire file because I have to. I said it was a linked list but it's more like a network linking things by priority, due date, and project. The only other way would be to keep everything in a direct-access file, and read or write each record as I needed it. That would have been far too slow. – Jennifer Oct 13 '17 at 14:54
  • Have not met anyone using turbo C for a long time... Was that some sort of study program? Or you just like it? :) – Cockabondy Oct 13 '17 at 15:01
  • I've been using it for a long time. It's fast and has great compile-time diagnostics (error messages). Once I get this working, I'll probably rewrite it in another language -- one that can give me plenty of stack space! – Jennifer Oct 13 '17 at 15:05

Your Answer

 
discard

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.