C++ ifstream has odd seg fault depending on where the file is located on disk

I have some C++ code (using ROOT libraries) I've inherited (~1.5k lines) and one of the first things I'm trying to do is solve a bug having to do with opening and reading a binary file which is passed as an argument at run time. Some code to represent the problem would look like:

[~/this]$ ./Make_RWQ_Tree /Users/me/this/that/mydata_f00000001.rwq
inFile: ./mydata_f00000001.rwq
outFile: ./mydata_f00000001.tru
Header Info:
a = 12
b = 345
c = 51
N = 100
G = 100
numEventsInFile = 1000
   r = 1
   s = 2
   t = 4
*** Show info for each of the events in the file normally ***

[~/this]$
[~/this]$ mv ./mydata_f00000001.rwq /Users/me/this/that/another/directory/deeper/
[~/this]$ ./Make_RWQ_Tree /Users/me/this/that/another/directory/deeper/mydata_f00000001.rwq
inFile: ./mydata_f00000001.rwq
outFile: ./mydata_f00000001.tru
Header Info:
a = 12
b = 345
c = 51
N = 100
G = 100
numEventsInFile = 1000

 *** Break *** segmentation violation



===========================================================
There was a crash.
This is the entire stack trace of all threads:
===========================================================

#5  0x00007fffffe007c5 in __memcpy ()
#6  0x00007f开发者_开发知识库ff87de59f7 in std::basic_streambuf<char, std::char_traits<char> >::xsgetn ()
#7  0x00007fff87dc7b19 in std::basic_filebuf<char, std::char_traits<char> >::xsgetn ()
#8  0x00007fff87dcd8c1 in std::istream::read ()
#9  0x0000000100001e25 in main (argc=<value temporarily unavailable, due to optimizations>, argv=<value temporarily unavailable, due to optimizations>) at Make_RWQ_Tree.cxx:175

So depending on where the file is I get a Seg Fault after it has successfully opened and read several values out of the file. Line 175 as reported is just a regular inFile.read.

I apologize that this might be very difficult to help without actual lines of code, but I don't think I can minimize the code to a small working version that illustrates it. Anyone have any experience with this kind of thing happening?

Someone's using a fixed size buffer for filenames. Look at the code parsing argv, or code that logs the filename.