From mint-bounce@lists.fishpool.fi Wed Jan 27 04:41:28 2010 Message-ID: <95937FACD324407D816DAEF5157D0B90@mercatus.local> From: "Jo Even Skarstein" To: References: <1F55D94972D147B8A69EF89653073145@mercatus.local> In-Reply-To: Subject: Re: [MiNT] Freeing child's base page Date: Wed, 27 Jan 2010 10:39:57 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8089.726 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8089.726 X-EsetScannerBuild: 6471 X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-to: mint-bounce@lists.fishpool.fi X-original-sender: joska@online.no Precedence: bulk List-help: List-unsubscribe: List-Id: X-List-ID: List-subscribe: List-owner: List-post: 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