Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Date: Fri, 7 Dec 2001 17:56:43 +0100 From: Henning Moll X-Mailer: The Bat! (v1.53d) Personal Reply-To: Henning Moll X-Priority: 3 (Normal) Message-ID: <671980027.20011207175643@gmx.de> To: Cliff Hones CC: cygwin AT cygwin DOT com Subject: Re[2]: problems with dlopen In-Reply-To: <200112071626.QAA09145@trillian.uk.aonix.com> References: <14214257250 DOT 20011207010527 AT gmx DOT de> <200112071626 DOT QAA09145 AT trillian DOT uk DOT aonix DOT com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hallo Cliff, Friday, December 07, 2001, 5:26:33 PM, you wrote: > If your suspicion is correct, then simply moving "state = 1" to before > the call of dlopen should do the trick, i.e.: > case 0: > state = 1; > handle = dlopen("cygwin1.dll", RTLD_NOW); > orig_malloc = (void *(*)(size_t)) dlsym (handle, "malloc"); > /*fall through*/ > -- Cliff You're right, that was an error. Unfortunately it doesn't solve the problem. Again, the same error while executing 'dlopen'. Now i think the problem ist not a recursive call of 'malloc' (for the moment), because i should be able to detect such recursive behaviour by setting a breakpoint in my own malloc... Hmm, and there is no recursion before the segfault. Sure, after the current problem is removed, dlopen may call malloc to get some memory. For that purpose i'll try to implement an additional state which then use a static memory array to provide the requested memory. Again, any suggestions? -- Best regards, Henning -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/