From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22415 invoked by alias); 29 Jun 2012 09:57:09 -0000 Received: (qmail 22397 invoked by uid 22791); 29 Jun 2012 09:57:08 -0000 X-SWARE-Spam-Status: No, hits=-3.5 required=5.0 tests=BAYES_00,KHOP_RCVD_UNTRUST,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mailgw2.z-ptx-11.fr.sopragroup.com (HELO mailgw2.z-ptx-11.fr.sopragroup.com) (81.80.239.194) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 29 Jun 2012 09:56:54 +0000 Received: from mailgw2.z-ptx-11.fr.sopragroup.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id E73EED01D9 for ; Fri, 29 Jun 2012 11:56:52 +0200 (CEST) From: Lenci Damien To: "cygwin@cygwin.com" Subject: Re: problem with fork() and temp dlls Date: Fri, 29 Jun 2012 09:57:00 -0000 Message-ID: <7925_1340963812_4FED7BE3_7925_5434_2_B03025C959FD1A4796D42DC68C9C0823046C652B@wancyexmbx01.ancy.fr.sopra> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com X-SW-Source: 2012-06/txt/msg00559.txt.bz2 > Looks like fork problems to me. Perhaps you need to rebase the DLLs you'= re > building? See the link below for more info: I've already done that, sorry I should have mentioned it. I made a simple testcase reproducing the module loading algorithm of nagios= : File mydll.c is only: int testvar =3D 42; Compiled with : gcc -shared -o mydll.dll mydll.c File mymain.c : =20 #include #include #include #include #include #include int main (void){ char output_file[80]; int dest_fd; int source_file; void *buf; struct stat st; void *dllhandle; int *testvar; snprintf(output_file, sizeof(output_file) - 1, "nebmodXXXXXX"); dest_fd =3D mkstemp(output_file); source_file =3D open("mydll.dll",O_RDONLY, 0644); fstat(source_file, &st); int buf_size =3D st.st_size; buf =3D malloc(buf_size); read( source_file, buf, buf_size); write(dest_fd, buf, buf_size); free(buf); fchmod(dest_fd, S_IRWXU); close(dest_fd); dllhandle =3D dlopen(output_file, RTLD_NOW | RTLD_GLOBAL); if (dllhandle =3D=3D NULL) { printf("Unable to load dll : %s\n", dlerror()); return 1; } unlink(output_file); if (fork()){ testvar =3D (int *)dlsym(dllhandle, "testvar"); printf("parent : %d\n", *testvar); } else{ testvar =3D (int *)dlsym(dllhandle, "testvar"); printf("child : %d\n", *testvar); } } Compiled with : gcc -o mymain mymain.c If I run this I got : $ ./mymain.exe 0 [main] mymain 6040 child_info_fork::abort: unable to map XXXXXX\tmp= \dllforktest\nebmod5Ix5re, Win32 error 126 parent : 42 If I change the dlopen to load the original dll: dllhandle =3D dlopen("mydll.dll", RTLD_NOW | RTLD_GLOBAL); It works fine... That means fork() try to reload the dll from file while it is already loade= d by the parent process and I'm wondering why. Is it a normal and wanted behavior? (don't think so, it works fine on debia= n) Is it not wanted but normal (windows restriction maybe)? Or is it some kind of bug in the fork implementation? Thanks, Damien Lenci -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple