 Relationships |
|
| Anonymous | Login | Signup for a new account | 11-10-2008 10:58 PST |
| Main | My View | View Issues | Change Log | Docs |
| Viewing Issue Simple Details [ Jump to Notes ] | [ View Advanced ] [ Issue History ] [ Print ] | ||||||||
| ID | Category | Severity | Reproducibility | Date Submitted | Last Update | ||||
| 0000732 | [BusyBox] Other | crash | always | 02-18-06 21:02 | 02-18-06 23:53 | ||||
| Reporter | rfelker | View Status | public | ||||||
| Assigned To | BusyBox | ||||||||
| Priority | normal | Resolution | won't fix | ||||||
| Status | closed | Product Version | |||||||
| Summary | 0000732: incorrect use of vfork leads to corruption/crash | ||||||||
| Description |
vfork is used in place of fork several places in busybox. As far as I can tell, they are all incorrect according to susv3 (http://www.opengroup.org/onlinepubs/009695399/functions/vfork.html) [^] and I have confirmed that the one in tar.c causes memory corruption/crash on implementations that actually provide a true vfork rather than just mapping vfork to fork. Specifics of the incorrect usage: dup2 and close are called after vfork. According to the spec, no function other than exec* or _exit may be called by the child process after vfork. |
||||||||
| Additional Information |
This was probably not detected because uClibc (and glibc?) map vfork to fork. The correct fix is just to replace the vfork call with fork, since it is not improving performance on uClibc/glibc systems anyway. |
||||||||
| Attached Files | |||||||||
|
|
|||||||||
|
Relationships |
|
|
Notes |
|
|
(0001107) rfelker 02-18-06 22:21 |
As you can see, this bug is filed under busybox. :) My bad for saying uClibc in the description. Everything else I said still applies (to busybox). |
|
(0001108) vapier 02-18-06 22:34 |
most of the time, vfork is used instead of fork so that busybox will work nicely on uClinux systems |
|
(0001109) rfelker 02-18-06 23:47 |
Ah, perhaps an option should be available then? Clearly BusyBox's use of vfork is not legitimate according to POSIX. Actually in the case of my crash, it turned out to be another issue causing it; with that addressed, vfork does not cause corruption/crash. However, in theory it could cause a crash, and it would probably be a good idea to make the conformant behavior optional (even if just via -Dvfork=fork or something..). |
|
(0001110) vapier 02-18-06 23:53 |
vfork doesnt say that it's incorrect, simply that the behavior is undefined in the linux world, this means that the child and parent process share the same bits of memory so running any calls in the child will affect the parent accordingly |
|
Issue History |
|||
| Date Modified | Username | Field | Change |
| 02-18-06 21:02 | rfelker | New Issue | |
| 02-18-06 21:02 | rfelker | Status | new => assigned |
| 02-18-06 21:02 | rfelker | Assigned To | => BusyBox |
| 02-18-06 22:01 | vapier | Note Added: 0001106 | |
| 02-18-06 22:21 | rfelker | Note Added: 0001107 | |
| 02-18-06 22:34 | vapier | Note Added: 0001108 | |
| 02-18-06 22:34 | vapier | Description Updated | |
| 02-18-06 22:34 | vapier | Note Deleted: 0001106 | |
| 02-18-06 23:47 | rfelker | Note Added: 0001109 | |
| 02-18-06 23:53 | vapier | Note Added: 0001110 | |
| 02-18-06 23:53 | vapier | Status | assigned => closed |
| 02-18-06 23:53 | vapier | Resolution | open => won't fix |
| Copyright © 2000 - 2006 Mantis Group |  |
