[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MiNT] Freeing child's base page

From: Miro Kropacek
Sent: Wednesday, January 27, 2010 9:00 AM
To: Jo Even Skarstein
Cc: MiNT Mailing List
Subject: Re: [MiNT] Freeing child's base page
So the problem is that the pointer in proc 1 now points to free memory. If it's Mfree'd then it belongs to the OS now. Of course it's illegal to access this memory now. If LDG does this, it must be considered a bug.
But again, we're freeing BP _only_ and BP contains some pointers to some parts of memory (text, data, bss etc) -- so it would make sense if I call Mfree (bp->p_data_segment ); but calling Mfree (bp) only? There must be something more.
I think we need more details on how LDG loads and access modules. How are the modules loaded? With Pexec? Are the modules at any point executed, or are the just called as subroutines from the parent? 


From your previous post:
I know where the bug is I just don't know why it happens, it seems like incorrect allocation in the first place, ldg_unload: 


if( ldg) {
       if( ldg->close) (*ldg->close)();
       Mfree( ((BASPAG *)ldg->baspag)->p_env);
       Mfree( ldg->baspag);
      ldg->baspag = NULL;
       }
crash occurs on the last line, ldg->baspage = NULL (!), if I comment this out, everything is OK. It seems that Mfree() frees 
more than it should (i.e. freeing also the memory where 'ldg' points to)
You say that you don't use the LDG TSR, which - if I understand the purpose of this TSR correctly - means that the module is loaded by the application and not shared. This implicates that the module is unloaded from memory when the calling application exits. So where and how is the actual unloading performed? If the module is unloaded by the time the code above is called, then the code is buggy.
Have you tried to comment out the two Mfrees in the code above but leave that last line in? If you still get a memory violation then the module is already unloaded and it's memory free'd to the OS. Then you just need to figure out when the module is actually removed from memory, and how it's supposed to happen :-)
Jo Even 

__________ Information from ESET NOD32 Antivirus, version of virus signature database 4808 (20100126) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com