opkg Segmentation fault

655 views
Skip to first unread message

jlc

unread,
Nov 17, 2009, 12:35:43 PM11/17/09
to opkg-devel
When I tried to upgrade from R215 to R330, opkg gives a
segmentation fault for update, upgrade, list, and install. It
seems to function OK for configure, list_installed and remove.

The releases up to R282 are OK, but releases R283 to R330
give the segmentation fault.

I am using opkg on a TiVo. Here is the output with verbose
set to 9:

# opkg -V 9 update
Function: pkg_vec_insert_merge. Adding new pkg=bash version=3.2
arch=mips
Function: pkg_vec_insert_merge. Adding new pkg=bind-utils
version=9.5.0 arch=mips
Segmentation fault

Here is the tail end of "strace opkg update":
open("/var/lib/opkg/lists/tivoware-mips", O_RDONLY|O_LARGEFILE) = 4
fstat64(4, {st_mode=S_IFREG|0644, st_size=38875, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
-1, 0) = 0x2aac3000
read(4, "Package: bash\nVersion: 3.2-1\nDep"..., 4096) = 4096
fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(3, 1), ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
-1, 0) = 0x2aac4000
ioctl(1, TIOCNXCL, {B38400 opost isig icanon echo ...}) = 0
write(1, "Function: pkg_vec_insert_merge. "..., 74Function:
pkg_vec_insert_merge. Adding new pkg=bash version=3.2 arch=mips
) = 74
write(1, "Function: pkg_vec_insert_merge. "..., 82Function:
pkg_vec_insert_merge. Adding new pkg=bind-utils version=9.5.0
arch=mips
) = 82
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++

PiX

unread,
Nov 17, 2009, 4:47:29 PM11/17/09
to opkg-...@googlegroups.com
Could you post your opkg.conf ?
> --
>
> You received this message because you are subscribed to the Google Groups "opkg-devel" group.
> To post to this group, send email to opkg-...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/opkg-devel?hl=.
>
>
>

--
Camille Moncelier
http://devlife.org/

Graham Gower

unread,
Nov 17, 2009, 5:40:11 PM11/17/09
to opkg-...@googlegroups.com
My mipsel device seems to have no such problems...

Could you attach the /var/lib/opkg/lists/tivoware-mips file too?
And if you have configured opkg with any non default options, it would
be useful to know.

-Graham

John L. Chmielewski

unread,
Nov 17, 2009, 7:40:08 PM11/17/09
to opkg-...@googlegroups.com
My configuration files are very simple and mostly copied from ipkg.
Attached is opkg.conf, tivoware-feeds.conf, and tivoware-mips.

The tivoware-mips file looks strange. The multiple lines in a description
have blank lines between them. Maybe a problem with the opkg-utils package
used.
> --
>
> You received this message because you are subscribed to the Google Groups "opkg-devel" group.
> To post to this group, send email to opkg-...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/opkg-devel?hl=.
>

--
John
opkg.conf
tivoware-feeds.conf
tivoware-mips

Graham Gower

unread,
Nov 17, 2009, 8:43:08 PM11/17/09
to opkg-...@googlegroups.com
r331 should fix the segfault, but there is definitely a problem with
the package list.

I've not looked at ipkg-utils/opkg-utils at all. What version of this
are people using? Perhaps it would be smart to reintegrate this with
opkg and get patches merged to ensure that everyone is using the same
version?

-Graham

jlc

unread,
Nov 17, 2009, 11:44:21 PM11/17/09
to opkg-devel
I was using r5712 from openmoko.org:
svn checkout http://svn.openmoko.org/trunk/src/host/opkg-utils
opkg-utils
Is there a more recent version somewhere else?

Graham Gower

unread,
Nov 18, 2009, 12:20:38 AM11/18/09
to opkg-...@googlegroups.com
2009/11/18 jlc <jlc...@gmail.com>:
> I was using r5712 from openmoko.org:
>    svn checkout http://svn.openmoko.org/trunk/src/host/opkg-utils
> opkg-utils
> Is there a more recent version somewhere else?

Not sure, but that version does not appear to be in active use by
either openembedded or openwrt.

-Graham

jlc

unread,
Nov 19, 2009, 12:57:31 PM11/19/09
to opkg-devel
I was able to find and fix the problem using opkg-utils/opkg-make-
index. The package list is now correct with multi-line descriptions.

There is a new problem with R331 to R339. The install or upgrade of
some (maybe all) packages hangs. I only tried a opkg upgrade from
R332 to R339 and a strace install on R332 and R339. Both hang, but
both install with R215, although it seems to take a long time.

Here is end of the output using: opkg -V9 install strace
Debug install_cmd: strace
pkg_info_preinstall_check: updating arch priority for each package
pkg_info_preinstall_check: update file owner list
Getting old from pkg_hash_fetch
Getting new from pkg_hash_fetch
best installation candidate for strace
adding strace to providers
strace arch=mips arch_priority=106 version=4.5.16
Found a valid candidate for the install: strace 4.5.16
New versions from pkg_hash_fetch 4.5.16
Versions from pkg_hash_fetch in opkg_install_by_name new 4.5.16
Function: opkg_install_by_name calling opkg_install_pkg
Function: opkg_install_pkg calling pkg_arch_supported
opkg_install_pkg
arch mips (priority 106) supported for pkg strace
Installing strace (4.5.16-1) to root...
Downloading http://tivoware.lasevich.net/tivoware/mips/opk/strace_4.5.16-1_mips.opk
opkg: interrupted. writing out status database
Nothing to be done
opkg: gzip aborted

Here is the tail end of strace (using a binary in a different
location):
lstat("/tmp/opkg-x6BdPy/strace-JzOC4n/control", 0x7fff73d8) = -1
ENOENT (No such file or directory)
open("/tmp/opkg-x6BdPy/strace-JzOC4n/control", O_WRONLY|O_CREAT|
O_TRUNC, 0666) = 6
fstat64(6, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
-1, 0) = 0x2aac6000
write(6, "Package: strace\nVersion: 4.5.16-"..., 656) = 656
close(6) = 0
munmap(0x2aac6000, 4096) = 0
utime("/tmp/opkg-x6BdPy/strace-JzOC4n/control", [2009/07/02-23:55:29,
2009/07/02-23:55:29]) = 0
chown("/tmp/opkg-x6BdPy/strace-JzOC4n/control", 0, 0) = 0
chmod("/tmp/opkg-x6BdPy/strace-JzOC4n/control", 0100644) = 0
read(4, "", 4096) = 0
wait4(8454, opkg: gzip aborted

<unfinished ...>

On Nov 18, 12:20 am, Graham Gower <graham.go...@gmail.com> wrote:
> 2009/11/18 jlc <jlcs...@gmail.com>:
>
> > I was using r5712 from openmoko.org:
> >    svn checkouthttp://svn.openmoko.org/trunk/src/host/opkg-utils

Graham Gower

unread,
Nov 19, 2009, 3:21:17 PM11/19/09
to opkg-...@googlegroups.com
Issue 29 appears to be what you are experiencing.
http://code.google.com/p/opkg/issues/detail?id=29

This unzip/unarchive code really all needs to go.

jlc

unread,
Nov 19, 2009, 7:21:52 PM11/19/09
to opkg-devel
R340 fixed the hang problem, but uncovered another problem. It creates
a <prog>.list file of zero bytes so "opkg files <prog> returns
nothing. I tried installing readline, which, and strace. All have a
zero length list file with R340.

On Nov 19, 3:21 pm, Graham Gower <graham.go...@gmail.com> wrote:
> Issue 29 appears to be what you are experiencing.http://code.google.com/p/opkg/issues/detail?id=29

Graham Gower

unread,
Nov 19, 2009, 8:12:25 PM11/19/09
to opkg-...@googlegroups.com
2009/11/20 jlc <jlc...@gmail.com>:
> R340 fixed the hang problem, but uncovered another problem. It creates
> a <prog>.list file of zero bytes so "opkg files <prog> returns
> nothing.  I tried installing readline, which, and strace.  All have a
> zero length list file with R340.
>

I cannot reproduce this, neither on i686 with an offline root nor on
mipsel without an offline root.

-Graham

John L. Chmielewski

unread,
Nov 20, 2009, 11:34:41 AM11/20/09
to opkg-...@googlegroups.com
What can I do to help track down the problem? I was able to try a
install with R300 and it created a filled strace.list file. I also
ran opkg -V9 on both R300 and R340 and have attached the files.

One thing I noticed was that the line:
Calling pkg_write_filelist from install_data_files
was only called once from R300 but was called 2 times from R340
strace-R300-V9
strace-R340-V9

Graham Gower

unread,
Nov 20, 2009, 4:06:39 PM11/20/09
to opkg-...@googlegroups.com
Could you provide strace output too? E.g. 'strace opkpg install foo'
as opposed to 'opkg install strace'.

Thanks for persevering.
-Graham

Graham Gower

unread,
Nov 20, 2009, 4:07:37 PM11/20/09
to opkg-...@googlegroups.com
Oh, and is your system non glibc based by any chance? (just trying to
determine how it differs from my own)

John L. Chmielewski

unread,
Nov 20, 2009, 4:48:52 PM11/20/09
to opkg-...@googlegroups.com
The TiVo uses glibc: libc.so.6

I was going to send the strace before but did not.

Attached is a strace on the install of minicom using R344.
It looks like it opens every list file. Should it be doing that?

On Sat, Nov 21, 2009 at 07:37:37AM +1030, Graham Gower wrote:
> Oh, and is your system non glibc based by any chance? (just trying to
> determine how it differs from my own)
>
> --
>
> You received this message because you are subscribed to the Google Groups "opkg-devel" group.
> To post to this group, send email to opkg-...@googlegroups.com.
> To unsubscribe from this group, send email to opkg-devel+...@googlegroups.com.
minicom-strace

Graham Gower

unread,
Nov 22, 2009, 6:24:14 PM11/22/09
to opkg-...@googlegroups.com
pkg_write_filelist is doing this:

open("//var/lib/opkg/info/minicom.list",
O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 4
close(4) = 0

So the file_hash table does not contain any entries for minicom. No idea why.
(pkg_write_filelist should iterate the pkg->installed_files instead of
iterating all packages' files anyway).

I suspect r318 or r324 is responsible.

Is there any chance you could test some more revisions to determine
which commit is responsible?

-Graham

PS: Opkg is opening every list file because it wants to determine
whether installing the new package will clobber any files from other
packages.

jlc

unread,
Nov 22, 2009, 11:35:28 PM11/22/09
to opkg-devel
I had to apply the issue 29 patch to run R318, R323, and R324 so opkg
did not hang. R318 and R323 list the minicom files OK. R324 does not
list the files, so you were correct in suspecting R324.

Graham Gower

unread,
Nov 23, 2009, 12:24:58 AM11/23/09
to opkg-...@googlegroups.com
Does r345 help? Perhaps the bogus fdopen parameter I added in r324 was
the problem here too?

-Graham

jlc

unread,
Nov 23, 2009, 12:50:34 AM11/23/09
to opkg-devel
Yes, r345 fixed the problem.

Graham Gower

unread,
Nov 23, 2009, 1:04:18 AM11/23/09
to opkg-...@googlegroups.com
2009/11/23 jlc <jlc...@gmail.com>:
> Yes, r345 fixed the problem.

Excellent. Thanks for testing.
Reply all
Reply to author
Forward
0 new messages