Opened 7 years ago

Closed 2 years ago

#190 closed defect (wontfix)

Libc path rewriting is not working for fork()ed processes

Reported by: ydario Owned by: bird
Priority: normal Milestone: libc-0.6.5
Component: libc-backend Version: 0.6.2
Severity: normal Keywords: klibccfg
Cc: stevenhl

Description

Use of the klibccfg pathrewriter dll works only for main process: child forked processes can use only predefined libc rewriting rules (e.g. /@tmpdir).

This could be a dll init fault.

Sample testcase:

#include <sys/stat.h>

#include <stdio.h>
#include <unistd.h>

//#define DIR "/@tmpdir"
#define DIR "/$e/dati/yuri"

void test_dir( void)
{
   int ret;
   struct stat st;

   printf( "%d test dir\n", getpid());
   ret = stat( DIR, &st);
   if (ret != 0) {
	printf( "%d test dir failed\n", getpid());
	return;
   }
   printf( "%d test dir ok\n", getpid());
}


void test( void)
{
   FILE* f;

   printf( "%d test file\n", getpid());
   f = fopen( DIR "/fax.odt", "rb");
   if (f == NULL) {
	   printf( "%d test file failed\n", getpid());
	return;
   }
   fclose(f);
   printf( "%d test file OK\n", getpid());
}

void main( void)
{
   printf( "pid %d\n", getpid());

   fork();

   test();
   test_dir();

}

Change History (4)

comment:1 Changed 7 years ago by ydario

Further tests with a debug version of the rewriter dll, shows that hook function is called only once for parent process.

So I think the bug is in libc, which does not initialize hooks in forked processes.

comment:2 Changed 4 years ago by bird

  • Component changed from baselayout to libc-backend
  • Status changed from new to assigned

comment:3 Changed 3 years ago by stevenhl

  • Cc stevenhl added

comment:4 Changed 2 years ago by bird

  • Resolution set to wontfix
  • Status changed from assigned to closed

The reason why this is still broken (I believe I tried to fix it once already) is that the DLL is not fork() friendly and comes with its own heap. The rewrite rules are all installed after fork(), but they seems to be pointing to uninitialized/zero memory (probably in the heap block of that hook DLL).

The best idea here, if this is still considered relevant, is to split the klibccfg.dll into a WPS and a kLibC-hook dll. Continue building the WPS one with VAC or whatever, but build the hook dll with gcc (making sure forking is enabled). Apart from fixing the problem of this defect, this will also avoid dragging SOM, WPS and (maybe) PM dependencies into console applications that are using kLibC. It will also save memory by dispensing with the unnecessary VAC/whatever heap.

Note: See TracTickets for help on using tickets.