memcpy not copying

Started by
21 comments, last by Spoonbender 16 years, 8 months ago
Quote:Original post by Driv3MeFar
template <typename T>T* Duplicate(T* pIn, int numObjs){    T* ret = new T[numObjs];    std::copy(pIn, pIn + numObjs, ret);    return ret;}


EDIT: Fixed bug.
Arguing on the internet is like running in the Special Olympics: Even if you win, you're still retarded.[How To Ask Questions|STL Programmer's Guide|Bjarne FAQ|C++ FAQ Lite|C++ Reference|MSDN]
Advertisement
Quote:Original post by dalleboy
Quote:Original post by Driv3MeFar
template <typename T>T* Duplicate(T* pIn, int numObjs){    T* ret = new T[numObjs];    std::copy(pIn, pIn + numObjs, ret);    return ret;}


EDIT: Fixed bug.


Oops. I figured I'd fucked something up. Thanks for the fix [grin].
If the problems are appearing randomly that sounds like you've stomped on a heap structure somewhere. Perhaps the OS thinks it put some heap structures in your memory and is altering a pointer within those structures (setting the 4 byte quantity to 0). Can you set a memory breakpoint on the buffer and see what triggers it?
I've tried this already. I think I can watch a 4 bytes memory space, but not a full buffer of > 1kb (or much more sometimes)
And the memory corruption isn't always at the same address. Plus, I only control one thread, all other are system created (DirectInput, XAct, IO, etc.)

At this point I'm starting to suspect a hardware failure but I wont jump to that conclusion just yet
This may be helpful or not... but maybe you can get more information (even if just a little) by logging the content of both buffers after the copy?

Cheers
-Scott

edit: Sorry nevermind... For some reason I read everything except for in the post right after you were like "In order to to debug, I did this:". Guess I need to wake up...
Quote:Original post by janta
@Driv3MeFar: Yeah there is. I'm not coding at home, I'm working on a large codebase like 1M lines of code and I cant afford to refactor everything. The team who originally designed the software made the choice not to use stl.


Had I a billion dollars, I would pay off everyone I could find in similar positions to quit their jobs and arrange boycotts of the responsible companies. It seems nothing else will kill these (code) monstrosities.

Quote:That's interesting. Looking at std::copy's signature I saw it required some iterators as inputs, I did not think that mere pointers could be used as iterators. I'll try this, thanks.


Of course pointers are iterators. Why do you think the iterator interface is designed so they look like pointers as much as possible? Remember, template code doesn't care about differences between types; it cares about syntactically valid constructs with the given type (ad-hoc polymorphism).
All right, if someone is still interested by my personal life, I realized that another thread (a system-spawned thread, probably XACT since problems occurs right after the audio module has been initialized) is currupting my data. I don't know how and when though. So memcpy is not guilty, as was to be expected.

Now I think I'm gonna have a hard time debugging this...

A quick question: do you know of any tool or method to watch a given range of memory area?

Side personal question to Zahlman: In what field do you work ? Do you have some experience with professionnal game programming ? I've worked in a couple of big professionnal commercial shipped projects and had far more problems with those that used STL that with those that did not. Of course I wouldn't draw any general conclusion from that fact.
If the corrupted memory location is the same between runs you can place break points when a memory location changes. It's very useful for finding overwrites.
Quote:Original post by janta
I've worked in a couple of big professionnal commercial shipped projects and had far more problems with those that used STL that with those that did not. Of course I wouldn't draw any general conclusion from that fact.

Since it's the game development business we're talking about there's a possibility that they didn't have much experience with the template library to begin with, which could possibly be one of many explanations.
Best regards, Omid
Quote:I've worked in a couple of big professionnal commercial shipped projects and had far more problems with those that used STL that with those that did not. Of course I wouldn't draw any general conclusion from that fact.


One problem might be the STL is old... Very old. We now work with the SC++L. Next problem, few take the time to learn how to properly use it. This is almost worse then not using it. It took me about a week to figure out the basics and with a bit of brain power the rest was easy to figure out as I used it.

Now I find people in the games industry are scared of certain changes. They're normally fine with hardware (though a lot ran crying over multi-cored processors I think lol) but things like using a new library freaks them out and they actively or passively resist it however they can.

I had a friend a year ago finish school and not have a clue what the SC++L was. He figured he could write better code. I then informed him the people that wrote it are far better coders then him and I are (at least currently, I have dreams darn it!) and its heavily tested code used by tens of thousands of other developers. He now loves it. Go figure. I think the slap to the back of his head helped a bit too but I have no scientific proof.

"Those who would give up essential liberty to purchase a little temporary safety deserve neither liberty nor safety." --Benjamin Franklin

This topic is closed to new replies.

Advertisement