segmentation fault

erikv11 · 10-09-2009, 10:23 PM

I am running a program that I have used a lot, it was written in c++ and I compiled it a while ago, run it periodically. It has its own directory in my Applications folder. I am not very well versed in Unix but know some basics and can follow instructions.

Today I tried to use input files that were corrupted. The program gave segmentation faults. Once I figured out the files were bad, I copy-pasted the data through BBEdit, saved, and was (more or less ... see below) able to run the new data through the program.

EXCEPT ...

The program processes a certain number of text lines. The two corrupted files had 20 or 12 text lines. If I use a file with 18 text lines as input, it runs fine. For example, I can choose any 18 out of the 20 lines in the formerly corrupt files. But if I use ANY text file with 20 lines or with 12 lines as input, I get a segmentation fault. Including text files with 20 line that ran just fine yesterday.

I tried dumping then recompiling the program - still the same problem, selective segmentation faults.

Any ideas, at all, how to fix this?

tia

hayne · 10-09-2009, 11:25 PM

A segmentation fault indicates that there is a bug in the program. The only way to fix it is to:
a) understand what the bug is
b) change the program to fix the bug
Both of these require programming expertise.

Note that some bugs do not happen all the time - only particular circumstances bring them to the surface.

tw · 10-10-2009, 12:29 AM

I'd be willing to bet (in this case) that when you processed your files through bbedit you processed them not quite right. could be something obvious (like a badly constructed data format) or something subtle (like tabs where you wanted spaces, commas where you need semicolons, unicode text where it can only handle ascii...). check a bit more carefully and re-edit if needed.

EatsWithFingers · 10-10-2009, 07:59 AM

I second Hayne's reply in that the C++ code has a bug. It sounds like you have the source code, but are not the author.

My guess is that the problem may be caused by a lack of new line or carriage return character on the final line of the 'corrupted' input files. What happens if you add a new line to the end of those files? (my thinking is that the code is looking for an end-of-line character but finds an end-of-file character instead).

Failing that, what happens with input files of length 4, 8 or 16? It's a long-shot but the number of lines in the 'corrupted' files are multiples of 4.

erikv11 · 10-10-2009, 04:24 PM

I checked all lengths 1 through 36 plus some random, higher length multiples, the following rule was not violated in any those tests: program returns a segmentation fault if and only if input file has a multiple of 4 lines.

The "corrupted" files were indeed corrupted (likely a formatting error like end of line etc) but that was a red herring. Passage through BBEdit fixes the corruption, then the files work unless they have a multiple of 4 input lines.

conclusion: bug in someone else's C++ code (or my compiler does not play nice? I am a rookie the fault could still be on my end)

interim solution: avoid input files with a multiple of length 4, send report to the author of LDhat

Thanks everyone for chiming in, it has helped me a great deal.

10-09-2009, 10:23 PM	#1
erikv11 Triple-A Player Join Date: Mar 2004 Posts: 61	segmentation fault I am running a program that I have used a lot, it was written in c++ and I compiled it a while ago, run it periodically. It has its own directory in my Applications folder. I am not very well versed in Unix but know some basics and can follow instructions. Today I tried to use input files that were corrupted. The program gave segmentation faults. Once I figured out the files were bad, I copy-pasted the data through BBEdit, saved, and was (more or less ... see below) able to run the new data through the program. EXCEPT ... The program processes a certain number of text lines. The two corrupted files had 20 or 12 text lines. If I use a file with 18 text lines as input, it runs fine. For example, I can choose any 18 out of the 20 lines in the formerly corrupt files. But if I use ANY text file with 20 lines or with 12 lines as input, I get a segmentation fault. Including text files with 20 line that ran just fine yesterday. I tried dumping then recompiling the program - still the same problem, selective segmentation faults. Any ideas, at all, how to fix this? tia

10-09-2009, 11:25 PM	#2
hayne Site Admin Join Date: Jan 2002 Location: Montreal Posts: 31,957	A segmentation fault indicates that there is a bug in the program. The only way to fix it is to: a) understand what the bug is b) change the program to fix the bug Both of these require programming expertise. Note that some bugs do not happen all the time - only particular circumstances bring them to the surface. __________________ hayne.net/macosx.html

10-10-2009, 12:29 AM	#3
tw Hall of Famer Join Date: Apr 2007 Posts: 4,262	I'd be willing to bet (in this case) that when you processed your files through bbedit you processed them not quite right. could be something obvious (like a badly constructed data format) or something subtle (like tabs where you wanted spaces, commas where you need semicolons, unicode text where it can only handle ascii...). check a bit more carefully and re-edit if needed. __________________ Philosophy is a battle against the bewitchment of our intelligence by means of language. -LW-

10-10-2009, 07:59 AM	#4
EatsWithFingers All Star Join Date: Feb 2005 Posts: 726	I second Hayne's reply in that the C++ code has a bug. It sounds like you have the source code, but are not the author. My guess is that the problem may be caused by a lack of new line or carriage return character on the final line of the 'corrupted' input files. What happens if you add a new line to the end of those files? (my thinking is that the code is looking for an end-of-line character but finds an end-of-file character instead). Failing that, what happens with input files of length 4, 8 or 16? It's a long-shot but the number of lines in the 'corrupted' files are multiples of 4. __________________ Question everything -- especially that which you already believe to be true.

Thread Tools
Show Printable Version Email this Page
Display Modes	Rate This Thread
Switch to Linear Mode Hybrid Mode Switch to Threaded Mode	Rate This Thread:

10-10-2009, 04:24 PM	#5
erikv11 Triple-A Player Join Date: Mar 2004 Posts: 61	I checked all lengths 1 through 36 plus some random, higher length multiples, the following rule was not violated in any those tests: program returns a segmentation fault if and only if input file has a multiple of 4 lines. The "corrupted" files were indeed corrupted (likely a formatting error like end of line etc) but that was a red herring. Passage through BBEdit fixes the corruption, then the files work unless they have a multiple of 4 input lines. conclusion: bug in someone else's C++ code (or my compiler does not play nice? I am a rookie the fault could still be on my end) interim solution: avoid input files with a multiple of length 4, send report to the author of LDhat Thanks everyone for chiming in, it has helped me a great deal.