next »

[surt]

Typically I'd presume stack overflow is such a case but the numbers seem implausibly small for it to be an issue with stack limitations (no recursion in there?).
Have you tried to see if the problem still occurs when allocating on the heap?

[InfiniteStateMachine]

the problem doesn't occur when allocating on the heap. It also doesnt occur when using alloca oddly enough. I'm not super familiar with the internals of alloca though. Maybe there's a difference.

as for the questions. It was originally inside the block scope of a loop that ran about 4 times max (declared, defined and used in that scope). As a test I moved it to function scope and assigned one char manually.

edit : I have a suspicion it may have to do with the photoshop SDK doing something weird. Although I can't think of what they could do to mess with stack allocation like that. There's also a 32->64 bit migration guide for plugins, I have everything done adobe recommends doing but I wonder if that could possible be a cause...

[standardcombo]

over-used?

It was too long a go to get into details, but it involved a huge tree structure with millions of points... Data started going into the wrong places, but I didn't go through the trouble of clearly understanding it due to a deadline. Changed to heap allocation and it was fixed.

[Garthy]

odd. I create a char[500] inside a local function then later do some image processing that uses malloc for everything. If I assign even one char in that array all my image data gets messed up. Sometimes it looks like a lot of zero's (all black) sometimes it's a random pattern of green.

If i make the char[] a char[250] it works fine. I suppose there's a chance the stack and heap are touching but I'm not totally sure, I'm gonna have to dump out the contents of my image buffers and that array and find out. This is for a photoshop plugin and they have a bunch of weird memory management stuff. Maybe I exceeded some adobe limit causing everything to go haywire.

It's not an issue because I don't need that char[] but it's one of those things I wish I knew the reason it happens. I also think it may have happened when the code for the image processing was refactored into its own method but I'd have to confirm that more thoroughly.

Could it be that you are running in an environment such that by the time your code is called, the stack is critically short of space? Or perhaps you are only allowed a small bit of stack space in the environment set up for the plugin?

One thing you could try is to allocate some extra space before and after the stack storage you are using, and fill it with guard values at the start of the call, and check that they are the same values at the end. It's possible that there are bugs in some of the calls you make while in the function that that are corrupting the stack. If you set this up and it fails, all you need to do is to keep adding guard checks until you can get it down to the single line or call that causes the corruption.

[Boreal]

Damn, parsing is hard.

Really hard.

Not wanting to use other libraries except for cross-platform stuff is going to be the death of me.

[InfiniteStateMachine]

odd. I create a char[500] inside a local function then later do some image processing that uses malloc for everything. If I assign even one char in that array all my image data gets messed up. Sometimes it looks like a lot of zero's (all black) sometimes it's a random pattern of green.

If i make the char[] a char[250] it works fine. I suppose there's a chance the stack and heap are touching but I'm not totally sure, I'm gonna have to dump out the contents of my image buffers and that array and find out. This is for a photoshop plugin and they have a bunch of weird memory management stuff. Maybe I exceeded some adobe limit causing everything to go haywire.

It's not an issue because I don't need that char[] but it's one of those things I wish I knew the reason it happens. I also think it may have happened when the code for the image processing was refactored into its own method but I'd have to confirm that more thoroughly.

Could it be that you are running in an environment such that by the time your code is called, the stack is critically short of space? Or perhaps you are only allowed a small bit of stack space in the environment set up for the plugin?

One thing you could try is to allocate some extra space before and after the stack storage you are using, and fill it with guard values at the start of the call, and check that they are the same values at the end. It's possible that there are bugs in some of the calls you make while in the function that that are corrupting the stack. If you set this up and it fails, all you need to do is to keep adding guard checks until you can get it down to the single line or call that causes the corruption.

Those are both very possible. I'll definitely do that test as well. I may get to the point where I just dump the contents of the data after each line in that function to try to see what's going on exactly.

[surt]

Not wanting to use other libraries except for cross-platform stuff is going to be the death of me.

Use a parser generator and you don't need no stinkin' libraries.

[framk]

Nothing quite like spending a Sunday afternoon reading through the SVG1.1 specification document...

[nikki]

Ough yeah svg, had that moment a few weeks ago, filthy stuff, glad I got it nuked in our office

[Sik]

My problem with comitee-made standards: they tend to be overly complicated for no real reason -.-' Also one of the reasons why I don't like COLLADA (it's like the extreme example of this).

[ThemsAllTook]

SVG is definitely a mess, but it's about the best you'll get as far as vector image formats go. Sure would be nice if there were a better alternative.

[Schrompf]

Oh, Collada... I left several angry remarks in the Assimp source when writing the loader for it. The amount of loops you have to jump through just to get some data is staggering.

So thanks for the note: when I need SVG, I'll just find some library and bend it to my will.

[Boreal]

So my map procedure is working great, except that it seems to iterate the list in reverse order.  I'm at a total loss as to why this is happening

[Boreal]

 

Turns out all I had to do was put the apply and recursive map procedures outside the return statement.

Code:

// this is C++, vastly simplified
Exp *car = apply(procedure, car(list));
Exp *cdr = map(procedure, cdr(list));
return(cons(car, cdr));

Hours and hours of frustrated staring to find out that this is the solution.
I swear I tried this near the beginning and it didn't work

[InfiniteStateMachine]

arg. Was using a mixed mode dll w/CLR

when I pass a const char * from an unmanaged compilation unit to a managed compilation unit it seems to come in like it was never assigned to :|

I decided to just remove the CLR portion and go back to win32. That was a lot easier. The reason I was using mixed mode in the first place was I was trying to see if I could get 2 way interop going. I can kind of, but I can't call to the instance of the dll in memory I need to target.

Decided to use named pipes instead.

[Udderdude]

Fun with recompiling games for DOS using DJGPP and Allegro.  You never realize just how little you gave a crap about how much RAM you were using until you're back to trying to cram it all into 16 MB ..

[Boreal]

Saw that AMD Catalyst wanted to update.  Got really excited that maybe AMD finally had their 4.5 driver ready.

 

[Udderdude]

AMD drivers will always be shit.

[Boreal]

AMD drivers will always be shit.

I can't believe I bought a 280x in May when I could have waited for a little bit and gotten a 970 or something.

[Sik]

Fun with recompiling games for DOS using DJGPP and Allegro.  You never realize just how little you gave a crap about how much RAM you were using until you're back to trying to cram it all into 16 MB ..

Yeah, my game uses 40MB of RAM which sucks =/ (although that's on a 64-bit system, on 32-bit Windows I get 24MB instead, which makes me wonder how much data got expanded in the process O_O and this is in C, not some language which is pointer-heavy internally)

Granted, in large part optimizations are the reason of that memory usage. Sprites are loaded as uncompressed 32-bit RGBA bitmaps. Sound effects are loaded as uncompressed 16-bit waveforms. (yes, decompressed at load time) Music is stored as pure Vorbis data (i.e. prerendered as opposed to some instrument-based format). It's not hard to see how much memory that can take up. Older systems prefered formats with much smaller footprint (e.g. 8-bit paletted instead of 32-bit RGBA), so if the game was designed for those systems chances are the RAM usage would be much smaller as well.

(EDIT: made last sentence a bit less confusing)