10:11 < oliford> is there a technical term for designating a peice of code 'first against the wall when the revolution comes' ?
10:12 <@RjY> deprecated?
10:12 < oliford> I have modified some already hacky code to cope with 3D vectors, but it crashes when I remove the debugging printf statement
10:12 < oliford> *3D data
10:12 < oliford> no, it is still very much necessary and in use
10:12 <@Blood_God> Sounds like the compiler doesn't like you then.
10:12 <@Blood_God> That or you've got some strange side-effects of the printf...
10:13 < df> run valgrind
10:13 < oliford> The offending code is quite simple...
10:13 < df> your problem is likely elsewhere
10:13 < oliford> totalBytes = sizeOfTypeCallBlah(); for(int i=0; i <rank; i++){ totalBytes *= dimSize[i]; printf("RAR! "); }
10:14 < oliford> removing the printf crashes scilab a few calls later
10:14 < oliford> yes, I am aware my problem here is 'scilab'
10:17 <@RjY> so all you're doing is calculating totalbytes, you're not allocating anything
10:19 <@RjY> also that *= looks weird
10:19 < df> oliford, please run valgrind.
10:21 <@RjY> i can't visualise this at all, if rank is 4 you're allocating a 4-dimensional array? is that right?
10:23 <@RjY> oh well never mind, even if you explained it i'm too stupid to understand
10:23 < oliford> df: I would, but I have no idea how to and this is not critical enough to require wasting the time
10:24 < df> valgrind ./foo
10:24 < oliford> I will, very shortly switch entirely to scilab5 which has a proper HDF5 interface and will make this entire piece of C hackery obsolete
10:24 < oliford> oh, ok
10:24 < oliford> err, yea, problem is that its a library used by scilab
10:25 < df> valgrind scilab
10:25 < df> it will run slow mind.
10:25 < oliford> ok
10:25 < df> so you want to have a script that shows the fault
10:25  * oliford apt-get's valgrind
10:26 < df> ie, create a script, that in the smallest number of ops creates the fault.  then valgrind scilab script (or whatever it needs)
10:27 < df> you may want to do --leak-check=no --log-file=out.log
10:27 < df> (those are arguments to valgrind)
10:27 < oliford> hmm, scilab has a nasty env setup script, any way todo that?
10:27 < oliford> *any easy way
10:28 < df> yeah, bash -x valgrind
10:28 < df> err not that
10:28 < df> yeah, bash -x scilab
10:28 < df> that will show you what it execs
10:29 < df> then use that instead -- you may see a few VAR=foo, (eg, LD_LIBRARY_PATH, etc.,) set them
10:29 < oliford> I know what it execs, but the script needs to be run
10:29 < oliford> right
10:30 < oliford> nope, so VAR=f00
10:30 < oliford> *nope, no VAR=foo
10:30 < oliford> but scilex (the actual exec) is still saying "you must set SCI= env var"
10:31 < growler> spongs
10:32 < oliford> ah, script layering, nvm got it
10:36 < oliford> fail, scilab can't alloc enough mem inside valgrind
10:36 < oliford> it's never as simple as you think it's going to be
10:42 < df> heh
10:42 < df> how soon is your upgrade?
10:43 < oliford> at this rate, its going to be today
10:44 < oliford> it doesnt crash with valgrind, even without the printf
10:44 < oliford> but one of the return variable goes missing back in scilab
10:45 < oliford> that is probably the problem, and scilab probably just crashes when trying to give the error, if it runs outside valgrindf
10:46 < oliford> nope, thats again because valgrind doesnt allow enough memory alloc
10:46 < oliford> oh ffs, i give up
10:46 < alexs_> wut?
10:47  * oliford --> lunch, then upgrade
10:49 < oliford> [data, rnk] = getH5DSet(sigFile,"/data"); if ~isdef("rnk"); error("The magic stability fairy is dead"); end;
10:49 < oliford> ah, need to googletranslate the menu first

