aliens

Author Topic: How to track a segmentation fault?  (Read 4411 times)

Offline Vangrimar1

  • Colonel
  • ****
  • Posts: 143
    • View Profile
How to track a segmentation fault?
« on: February 17, 2020, 02:48:04 pm »
During the generation of a random battle, a "Segmentation fault?" error is very common. How to find out what exactly causes it? It uses X-Com Files and a mod of its own assembly.

Offline Meridian

  • Global Moderator
  • Commander
  • *****
  • Posts: 9091
    • View Profile
Re: How to track a segmentation fault?
« Reply #1 on: February 17, 2020, 03:12:49 pm »
If the log message doesn't have any additional information, then the only way to find out what is wrong, is to debug/trace using a debugger.

Offline Rubber Cannonball

  • Colonel
  • ****
  • Posts: 195
    • View Profile
Re: How to track a segmentation fault?
« Reply #2 on: February 17, 2020, 09:38:59 pm »
During the generation of a random battle, a "Segmentation fault?" error is very common. How to find out what exactly causes it? It uses X-Com Files and a mod of its own assembly.

Mods generally don't support every combination possible through the quick battle menu.  For instance, a particular ufo might be looking for a unit rank that the mod didn't define for the race or faction chosen.


As for "Segmentation fault" followed by "Core dumped", I saw that many a time back in college learning C.  I know OXC and OXCE are C++, but it seems an opportunity to improve upon C was missed there.  The Basic interpreter on the Apple ][+ in high school gave better error messages.  Same with Pascal on the Apple and later on the college Gould mainframes.  Even Fortran gave better compile time and run time error messages than C did, when C even bothered to give one at all.  I would write my program in C, then wade through all the obscure "Syntax error on line 123" and similar error messages and warnings.  Funny thing was, the error was almost always somewhere else than line number reported.  Finally, a clean compile, lets run it.  And of course an almost immediate crash with "Segmentation fault, core dumped"  Debugger tools?  Students didn't get access to those if they even existed back then.  So then I would resort to putting various debugging printf statements all over the code to try to figure out what was going on.  And even that didn't always work as some of the output before the crash would get flushed instead of shown.  Strangely enough, I think I preferred debugging assembly over C.  There were no error messages in assembly.  Just load the code into memory and run it.  Of course it wouldn't seem to do anything.  So I would halt the cpu and then wonder how the program counter got way outside the program.  But assembly instructions are so simple; it just takes a bunch of them to do anything.  As opposed to C where it is entirely possible to create valid but so cryptically, humanly indecipherable statements.

TLDR:
In my day, we had to walk 5 miles to school every day uphill both ways, in the rain, in the dark, with the cold wind in our faces.  And we liked it.