| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
<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
|
| |
|
|
| |
git-svn-id: http://opkg.googlecode.com/svn/trunk@332 e8e0d7a0-c8d9-11dd-a880-a1081c7ac358
|
| |
|
|
| |
git-svn-id: http://opkg.googlecode.com/svn/trunk@304 e8e0d7a0-c8d9-11dd-a880-a1081c7ac358
|
| |
|
|
| |
git-svn-id: http://opkg.googlecode.com/svn/trunk@303 e8e0d7a0-c8d9-11dd-a880-a1081c7ac358
|
| |
|
|
| |
git-svn-id: http://opkg.googlecode.com/svn/trunk@280 e8e0d7a0-c8d9-11dd-a880-a1081c7ac358
|
| |
|
|
| |
git-svn-id: http://opkg.googlecode.com/svn/trunk@233 e8e0d7a0-c8d9-11dd-a880-a1081c7ac358
|
| |
|
|
|
|
|
|
| |
s/strndup/xstrndup/
Thanks to Graham Gower <graham.gower@gmail.com>
git-svn-id: http://opkg.googlecode.com/svn/trunk@224 e8e0d7a0-c8d9-11dd-a880-a1081c7ac358
|
| |
|
|
|
|
|
|
|
|
| |
Modified seek_sub_file since the fgetc in the for loop
was very slow when installing huge packages.
A test on my machine showed a 4x gain when installing
a large package (23Mib)
git-svn-id: http://opkg.googlecode.com/svn/trunk@222 e8e0d7a0-c8d9-11dd-a880-a1081c7ac358
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
1. provide opkg with a tar file that has a link name that is 100
characters
or
2. provide opkg with a tar file that has a 'path_prefix' of 155
characters.
Thanks to pblack88@gmail.com
http://code.google.com/p/opkg/issues/detail?id=21
git-svn-id: http://opkg.googlecode.com/svn/trunk@217 e8e0d7a0-c8d9-11dd-a880-a1081c7ac358
|
| |
|
|
|
|
|
|
|
| |
http://www.crisos.org/flyspray/index.php?do=details&task_id=10
Fix issue:
http://code.google.com/p/opkg/issues/detail?id=4#c5
git-svn-id: http://opkg.googlecode.com/svn/trunk@214 e8e0d7a0-c8d9-11dd-a880-a1081c7ac358
|
| |
|
|
|
|
|
|
|
|
|
| |
Propagate gz_open() errors to caller function.
This is not enough, it is still needed to check deb_extract return value
everywhere in libopkg/pkg_extract.c
Signed-off-by: Antonio Ospite <ospite@studenti.unina.it>
git-svn-id: http://opkg.googlecode.com/svn/trunk@205 e8e0d7a0-c8d9-11dd-a880-a1081c7ac358
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Frans Meulenbroeks wrote:
> Anyway, appending the 0 byte is no good as tar_entry->name[100] is
> already out of bounds.
http://tiny.cc/964UD looks good enough. It's interesting that we have
to trace bugs already fixed upstream years ago.
http://lists.linuxtogo.org/pipermail/openembedded-devel/2009-March/008510.html
git-svn-id: http://opkg.googlecode.com/svn/trunk@203 e8e0d7a0-c8d9-11dd-a880-a1081c7ac358
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Frans Meulenbroeks
http://groups.google.com/group/opkg-devel/browse_thread/thread/23c3557277de0f2e
If a file name in a tar archive is exactly 100 bytes long the name
field is completely filled and there is no terminating null byte;
so extraction of the file will yield a name that is extended with the
mode (e.g. 000644).
The attached patch cures it although there might be better solutions.
The problem is also in busybox tar and reported there too.
Frans.
git-svn-id: http://opkg.googlecode.com/svn/trunk@201 e8e0d7a0-c8d9-11dd-a880-a1081c7ac358
|
| |
|
|
|
|
|
| |
Waiting for the patch fixing bugs.
git-svn-id: http://opkg.googlecode.com/svn/trunk@192 e8e0d7a0-c8d9-11dd-a880-a1081c7ac358
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
----------
This patchset updates the libbb stuff to use a vfork() version of
gz_open, called gzvopen. This is done because a standard fork will
duplicate the entire address space. This will invoke the OOM
(out of memory) killer on small-memory machines, because most often
by the time we unzip any package, we've read the entire package
database into memory already. By using vfork() and immediatly
execing the external gunzip utility, we avoid the need to clone the
entire address space.
Yes, this is actually **LESS** efficient than the original way!
But there is no way to (currently) dodge the OOM killer on a
per-process basis, so the alternatives are to either change the
OOM killer behavior system-wide, or to use this workaround.
Mike Westerhof, Dec 2008
git-svn-id: http://opkg.googlecode.com/svn/trunk@190 e8e0d7a0-c8d9-11dd-a880-a1081c7ac358
|
| |
|
|
| |
git-svn-id: http://opkg.googlecode.com/svn/trunk@148 e8e0d7a0-c8d9-11dd-a880-a1081c7ac358
|
| |
|
|
|
|
|
|
| |
running libopkg_test
git-svn-id: http://opkg.googlecode.com/svn/trunk@116 e8e0d7a0-c8d9-11dd-a880-a1081c7ac358
|
| |
|
|
| |
git-svn-id: http://opkg.googlecode.com/svn/trunk@85 e8e0d7a0-c8d9-11dd-a880-a1081c7ac358
|
| |
|
|
| |
git-svn-id: http://opkg.googlecode.com/svn/trunk@8 e8e0d7a0-c8d9-11dd-a880-a1081c7ac358
|
|
|
git-svn-id: http://opkg.googlecode.com/svn/trunk@3 e8e0d7a0-c8d9-11dd-a880-a1081c7ac358
|
