0

I've wrote a command line utility for extracting text from DXF files. My utility is named drawingtotext. Assuming a directory structure like this(Linux OS):

/home/dave/dxfs/

with a bunch of DXF files in the dxfs folder. From that location, assuming a file exists named "P1-1522-YI-WD-0403r1.dxf", running drawingtotext like this fails:

drawingtotext P1-1522-YI-WD-0403r1.dxf

with error: Segmentation fault (core dumped)

running drawingtotext ~/dxfs/P1-1522-YI-WD-0403r1.dxf gives me what I expect plus this at the end:

*** Error in 'drawingtotext': free(): invalid next size (fast): 0x0000000002031170 ***

with a backtrace and huge memory map.

Now, moving that file up a directory (/home/dave/ instead of /home/dave/dxfs/) results in exactly the results I'm looking for with no error. Renaming the file to something else like "mydxf.dxf" and keeping it in /home/dave/dxfs/ fixes the issue as well.

My question is how and why does the location of the file change the behaviour of my program and how do I fix it?

The code is here: http://www.github.com/davidworkman9/drawingtotext/

the main file is called "AutoCADConverter.cpp"

Dave
  • 2,506
  • 2
  • 20
  • 27
  • 1
    One clear problem is that you're not managing resources properly, using RAII. You're using owning raw pointers and `new`/`delete`. Use `std::unique_ptr` instead. – bames53 Jul 17 '13 at 15:47
  • Most of the code was not written by me, it was a utility that I modified to make it do what I wanted it to do, it was written before smart pointers became a part of the standard. That being said, my question is how does simply changing the filename fix the issue? – Dave Jul 17 '13 at 16:43
  • It's likely that the program has undefined behavior somewhere, so seemingly innocent differences in input lead to unexpectedly different output. For example changing the input filename length might change the size of a buffer, and some potential out-of-bounds access might happen or not happen depending on the size of the buffer. – bames53 Jul 17 '13 at 17:07
  • There are tools to help figure out what's wrong; you can turn the warning level on your compiler up to catch some simple things; if your compiler provides or you otherwise have access to a static analyzer, it may find more complex problems. There are also tools to instrument your program to dynamically detect UB, such as [clang's `-fsanitize` tools](http://clang.llvm.org/docs/UsersManual.html#controlling-code-generation) or [valgrind](http://valgrind.org/). – bames53 Jul 17 '13 at 17:18

1 Answers1

0

For your first error with drawingtotext P1-1522-YI-WD-0403r1.dxf command, are you sure the executable was in the same folder as P1-1522-YI-WD-0403r1.dxf?

The second error occurs when you free memory that has not been allocated. From looking at your code, this error must be occurring on the delete input or delete output lines near the end, seeing as that's the only place you're freeing any memory.
You said

"running this gives me what I expect plus this [error] at the end?"

If the output is created just like you want, and the only thing wrong is this error, then you can account for it by adding:

if (input != null) delete input;
if (output != null) delete output;

to avoid freeing memory that is not allocated. But again this only fixes your problem if the output is correct like you said, this works, but it may be indicative of a larger error.

You should run the program with Strace so you can see the system calls before the seg fault and free() error.

Optox
  • 630
  • 4
  • 9
  • the executable is in /usr/local/bin so it's global. I tried wrapping input and output in a null check with no success. If my input file is "P1-1522-YI-WD-0403r1.dxf" and I change it to "P1-1522-YI-WDA-0403r1.dxf" (difference being adding an "A" after "YI-WD") the error doesn't present itself and everything runs fine... I'll try using Strace. – Dave Jul 17 '13 at 15:41
  • `if (input != null) delete input;` won't change anything. It's already perfectly legal to `delete` a null pointer; `delete` is defined to do nothing when given a null pointer. – bames53 Jul 17 '13 at 16:00
  • @bames53 sorry, I mostly code in C. So if thats the case then a free error doesn't make sense to me. – Optox Jul 17 '13 at 16:28