Segfault trying to load NORMAL.BAM (and solution)

[sqweek]

So I've just recently got into OSS and switched over to linux and I thought 'hey i seem to recall hearing about an open source Infinity Engine in development, wonder how that is going...' (not that i've been anywhere near the IE in like 2 years but i have happy memories of alt.games.baldurs-gate).

 

Anyway, reminiscing/introduction aside, after doing battle with the installation procedure (which included such victories as 'updating SDL', 'updating a bunch of X stuff in the process of updating SDL cause Debian said so', 'transitioning from Xfree to X.org half-intentionally [the other half was ignorance]', 'X.org having trouble starting', 'NVidia driver refusing to compile', 'forgetting to rerun /sbin/lilo so i've been booting 2.6.9 rather than 2.6.11 for like the last month', and finally 'huh, make install?') -- after all that I ran into a problem which doesn't look like my own stupid fault.

 

Anyway, reminiscing/introduction aside, ...no wait i already pretended to be past that didn't i?

 

 

The symptom

GemRB crashes with a Segmentation Fault on startup just after trying to load NORMAL.BAM

 

The cause

gemrb $ stat '-c%A %n' Cache

drw------- Cache

 

Yup, no execute permissions on the Cache directory. Which meant that an unchecked fopen (or similar) call was returning NULL (actually how i tracked down the problem -- Debug Executables+OSS = rox. well, after you figure out the wrapper script anyway [what's with that?]).

I had a brief investigation into how the directory was being created, but it wasn't in the tar file so it must have been in the Makefile(s) and frankly Other People's Build Process = wtf (nothing obvious showed up with grep).

 

The solution

gemrb $ chmod 755 Cache

 

 

So obviously, not high priority I'm just making you aware of it aswell as making a solution public so if anyone else runs into it they might be able to fix it up without having to do the investigative work (hopfully 'Segfault NORMAL.BAM' is enough to catch searches... unless they like search for SEGMENTATION VIOLATION or SIGSEGV or SIGNAL 11 or SIGNAL 291 or something)

The most obvious hack fix to me would be just check the cache directory is writable somewhere during startup (rather than checking every fricken fopen).

 

 

*rereads post*

rofl. i love being me. Hiyas

[Guest avenger_work]

Welcome on board.

 

Interesting that you are the first who ran into this.

Are you sure the gemrb make process created the Cache folder with insufficient privileges?

 

... after some time...

 

Hmm, probably the problem is with mkdir(CachePath,S_IREAD|S_IWRITE); in Interface.cpp