Fix hang in waitpid, exposed by r310. Patch from Enrico Scholz
authorgraham.gower <graham.gower@e8e0d7a0-c8d9-11dd-a880-a1081c7ac358>
Thu, 19 Nov 2009 22:40:55 +0000 (22:40 +0000)
committergraham.gower <graham.gower@e8e0d7a0-c8d9-11dd-a880-a1081c7ac358>
Thu, 19 Nov 2009 22:40:55 +0000 (22:40 +0000)
commitb6c404659768c0be9d4d7b93a8d475c76ee26380
tree876956fca419e79ccd2ad4b630ec270e112661f2
parentc03e55b08e74a0d6ddb8cfd3d691444dd911a90e
Fix hang in waitpid, exposed by r310. Patch from Enrico Scholz
 <enrico.scholz@informatik.tu-chemnitz.de>, his analysis follows.

libbb/unarchive.c: prevent opkg hang when subprocess is stuck in a
write() call on a filled pipe and main process (which assumes that end
of data from pipe has been reached) waits for this died subprocess.

This patch swaps the original wait(pid) + close(pipe) sequencse so
that pipe is closed first.

The 'ar' code path has been fixed too by breaking the loop when
requested data have been found.  Previously, the loop continued at
the (wrongly calculated) next position in the stream.  The patch
moves the stream cleanup at a better place.

Variable declarations were moved to inner scopes too to ease detection
of broken deallocation.

NOTE: the

| f = fdopen(...);
| while (... /* do fread(f) */ ...) { /* ==1== */
|  /* this is done in gz_open() */
|  pid = fork();
|  if (pid == 0) {
|  fread(f); /* ==2== */
|  _exit(0);
|  }
| }

code looks problematic because '==2==' might update f's internal
buffer.  As ==2== is done in an own process, these changes are not
seen by ==1==.  It works only because gz_open() is called not more
than one time and the loops break (after the patch).

git-svn-id: http://opkg.googlecode.com/svn/trunk@340 e8e0d7a0-c8d9-11dd-a880-a1081c7ac358
libbb/unarchive.c