Re: problem with fork() and temp dlls

[Larry Hall (Cygwin)]

On 6/28/2012 5:08 AM, Lenci Damien wrote:

Hello,

I am currently trying to port Nagios on Cygwin and I'm having a issue (among 
others ^^) when trying to use modules.
Here is how Nagios loads modules :

- Create a temporary file using mkstemp()
- Copy module into this temp file
- Load module from temp file with dlopen()
- Delete temp file (on startup, not when nagios process is terminated)

Here is the problem message :

0 [main] nagios 3624 child_info_fork::abort: unable to map 
\var\nagios\spool\checkresults\nebmodE56bUw, Win32 error 126

Sometimes return code(I think this is the return code) is 1 :

1 [main] nagios 2364 child_info_fork::abort: unable to map 
\var\nagios\spool\checkresults\nebmodE56bUw, Win32 error 126


Looks like fork problems to me.  Perhaps you need to rebase the DLLs you're
building?  See the link below for more info:

   

--
Larry

_

A: Yes.
> Q: Are you sure?
>> A: Because it reverses the logical flow of conversation.
>>> Q: Why is top posting annoying in email?

--
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

Re: problem with fork() and temp dlls

[Lenci Damien]

> 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 = 42;


Compiled with :
gcc -shared -o mydll.dll mydll.c


File mymain.c :
 
#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, "nebmodXX");
dest_fd = mkstemp(output_file);
source_file = open("mydll.dll",O_RDONLY, 0644);

fstat(source_file, &st);
int buf_size = st.st_size;
buf = 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 = dlopen(output_file, RTLD_NOW | RTLD_GLOBAL);

if (dllhandle == NULL) {
printf("Unable to load dll : %s\n", dlerror());
return 1;
}

unlink(output_file);

if (fork()){
testvar = (int *)dlsym(dllhandle, "testvar");
printf("parent : %d\n", *testvar);
}
else{
testvar = (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 
XX\tmp\dllforktest\nebmod5Ix5re, Win32 error 126
parent : 42

If I change the dlopen to load the original dll:
dllhandle = dlopen("mydll.dll", RTLD_NOW | RTLD_GLOBAL);

It works fine...

That means fork() try to reload the dll from file while it is already loaded by 
the parent process and I'm wondering why.
Is it a normal and wanted behavior? (don't think so, it works fine on debian)
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

Re: problem with fork() and temp dlls

[marco atzeri]

On 6/29/2012 11:56 AM, Lenci Damien wrote:

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.


just to crosscheck, did you ran only
   rebaseall
or
   rebaseall -T list_of_my_built_files


rebaseall, as standard, is not aware of dll's not reported in the
/etc/setup/*.gz lists.



Thanks,

Damien Lenci



Marco

--
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

Re: problem with fork() and temp dlls

[Lenci Damien]

>>>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. 

>just to crosscheck, did you ran only
>   rebaseall
>or
>   rebaseall -T list_of_my_built_files
>
>
>rebaseall, as standard, is not aware of dll's not reported in the
>/etc/setup/*.gz lists.
>

I ran only rebaseall but it works with the "original" dll, and I just can't run 
a rebaseall between the creation and the load of the temporary file.
BTW, the error is not the same as the usual "unable to Remap  to same 
address as parent".
Here, its "unable to map " with error 126 which means the dll has not been 
found (indeed, the file is deleted), imo, the child process just shouldn't 
search for it as it's already loaded by its parent.

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

Re: problem with fork() and temp dlls

[marco atzeri]

On 6/29/2012 2:07 PM, Lenci Damien wrote:

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.



just to crosscheck, did you ran only
   rebaseall
or
   rebaseall -T list_of_my_built_files


rebaseall, as standard, is not aware of dll's not reported in the
/etc/setup/*.gz lists.



I ran only rebaseall but it works with the "original" dll, and I just can't run 
a rebaseall between the creation and the load of the temporary file.


do not bet that you do not need it.


BTW, the error is not the same as the usual "unable to Remap  to same address as 
parent".
Here, its "unable to map " with error 126 which means the dll has not been 
found (indeed, the file is deleted), imo, the child process just shouldn't search for it 
as it's already loaded by its parent.


in this case you will need to add the location of the new DLL's to
the PATH, or you can use LD_PRELOAD

http://cygwin.com/ml/cygwin/2009-05/msg00822.html


Damien Lenci


Regards
Marco


--
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