Programming Forums - shared library/dll problem

Page 1 of 2

Show 40 post(s) from this thread on one page

Programming Forums (http://www.programmingforums.org/forumindex.php)

- C++ (http://www.programmingforums.org/forum15.html)

- - shared library/dll problem (http://www.programmingforums.org/showthread.php?t=13517)

rwm	Jul 9th, 2007 9:57 AM

shared library/dll problem

heya!

im having a bit of trouble with allocating memory across dll/so boundaries. how can i force all code in the application to use the same heap?

hope someone can help? thanks! :D

Eoin	Jul 9th, 2007 1:47 PM

This is a classic problem on windows when you link with a dll which was itself linked against a different CRT, say maybe the DLL uses the multi-threaded runtime while your app uses single-threaded

If you compile the DLL yourself then just make sure you used the same runtime, if you only have the DLL in binary then you have to make your program use the same one.

I'm not sure how you could go about forcing code the use the same heap. On windows for example the one process can have multiple heaps even if it's all using the same runtime.

On the Unix side I really don't have the experience to say either way.

At what level are you allocating and deallocating memory? I.e. raw APIs (say HeapAlloc on win) or C++ style with new and delete.

rwm	Jul 10th, 2007 3:42 AM

hey Eoin!

thanks for the reply! mmm, well i dont have any experience with this either!

my problem is ive written a plugin for maya (www.autodesk.com) and it uses alot of heap memory, well what happens is that is crashing very severly, and i eventually found out that the code is not in the same dll/so space, so not the same heap memory...

what i assumed was that in order to prevent this i would have to make sure my code was allocating in the same heap as the maya?

im using new and delete...

i would really appreciate any further comments!

:D

PS: what i really dont understand is im actually compiling all the code into the plugin, theres no external libraries or stuff, just a plain dll/so

Eoin	Jul 10th, 2007 8:21 AM

Generally speaking the issue which arises with memory is attempting to allocate and then free memory with two incompatible methods. So with Win APIs you wouldn't use GlobalFree to free memory allocated with HeapAlloc. In C++ you wouldn't want to delete an array allocated with new[] say. (I'm typing these examples off my head so please excuse any brain farts.)

So the important thing you need to ensure is that Maya doesn't try to free any memory you've allocated. If it those do so there should be documentation detailing the correct way for your plugin to allocate that memory in the first place. I'd be surprised if it does this because of how many issues it could throw up.

You mentioned about dll/so space, I can again only try and explain what happens on Windows- dlls are loaded into the same process space as the executable. So it should be safe for Maya code to read and write to memory your plugin has allocated up until your plugin frees that memory.

Two possible causes your your issue might therefore be- 1) You allocate a block of memory small than Maya was expecting so it reads out of bounds. And 2) You free the memory before Maya was finished with it causing a read or write access error.

rwm	Jul 10th, 2007 8:59 AM

heya!

thanks for the reply!

ok i know, there are no new/delete mismatches (as far as i know), the problem occurs in this simple example:

class Parser {

        public:

                Parser() {

                        p = 0;

                }

                virtual ~Parser() {

                        Cleanup();

                }

                virtual void Cleanup() {

                        delete p;

                        p = 0;

                }

        private:

                int *p;

};



class ParserTranslator : public Parser,public MPxFileTranslator {

        public:

                ParserTranslator() : Parser() {

                }

                ~ParserTranslator() {

                }

                static void *creator() {

                        return new ParserTranslator;

                }

        private:

                //

};

the result is a seg fault...

its clearly nothing im doing wrong in my class code, heres a reply i got from the API boards

Quote:

Have you tried to simply not use multiple inheritance and make the Parser class a member. multiple inheritance is generally a bad thing in my opinion

i did originally make the parser calss a member, since i ran into the same problem, but now i would like to know how i can fix this problem...

hope you can help!

thanks! :D

Eoin	Jul 10th, 2007 9:35 AM

I've never really liked the blanket statement that multiple inheritance is a bad thing. But if you never think you'll refer to ParserTranslator from a Parser* then making it a member is probably a good idea.

On to the issue at hand, the problem probably lies with the parser class and what happens when it gets copied. Instead of me trying to crudely explain things I'll point you to this gem of an article, The Law of The Big Two, by two excellent authors. If after reading that and giving things a try you still have problems post your new code and I'll take a look.

As a p.s. Matthew Wilson's book, Imperfect C++, is an excellent read.

rwm	Jul 10th, 2007 10:06 AM

thanks dude! that looks like a really interesting read! gonna read it at home, actually busy with a vfx job at the moment! will get back as soon as i read it!

:D

rwm	Jul 11th, 2007 4:47 AM

heya!

well i read the article, im not doing anything wrong with regard to that, its specifically a dll/so problem, unless im wrong?

Eoin	Jul 11th, 2007 8:22 AM

Well are you absolutely sure that the Parser class never gets copied? As it stands in the code sample you posted it is not safe to copy so you should at least disable copying as the article suggests

class SelfishBeastie

{

  . . .



private:

  SelfishBeastie(const SelfishBeastie&);

  SelfishBeastie& operator=(const SelfishBeastie&);

};

You be surprised what copies could be taking place behind the scenes.

Better yet use a boost::shared_ptr to manage that int*, then just as the article mentions you can forget about the destructor.

rwm	Jul 11th, 2007 8:59 AM

hey Eoin! yeah you were right, i was forgetting to explictly set the copy constructor/assignment but that wasnt the problem, a real valid point though! thanks for pointing out!

as you can see the following code

class Parser {

    public:

        Parser() : file(0) {}

        virtual ~Parser() {

            Cleanup();

        }

        void Cleanup() {

            delete[] file;

            file = 0;

        }

    private:

        char *file;

        //disallow copying

        Parser(const Parser &) {}

        Parser &operator=(const Parser &) {}

};

and

class Parser {

    public:

        Parser() : file(0) {}

        Parser(const Parser &other) {

                *this = other;

        }

        virtual ~Parser() {

                Cleanup();

        }

        Parser &operator=(const Parser &right) {

                if(right.file) {

                        file = new char[strlen(right.file)+1];

                        strcpy(file,right.file);

                } else

                        file = 0;

        }

        void Cleanup() {

            delete[] file;

            file = 0;

        }

    private:

        char *file;

};

both cause the same crash as before... buggery bollocks! im busy reading up stuff on how libraries work on linux, how to compile/create etc maybe that will give me an idea...

any suggestions? any responses would be greatly appreciated!

thanks :D

All times are GMT -5. The time now is 2:47 AM.

Page 1 of 2

Show 40 post(s) from this thread on one page