Created attachment 4970 [details] test_example.ipk Originally reported by Ashlin Inwood <ashlin.inwood@gmail.com> via the opkg-devel mailing list. [1] # Setup Opkg 0.6.2 built through Buildroot for ARM32. 1. Start with a clean install of opkg, no packages installed. 2. Install test pkg, "sudo opkg install ./test_example.ipk" , (file attached) 3. Run "sudo opkg list-upgradable -V4" a few times. # Error Log ``` opkg_conf_parse_file: Loading conf file /etc/opkg/opkg.conf. pk[ 2537.036481] audit: type=1701 audit(1692852714.599:20): auid=4294967295 uid=1000 gid=0 ses=4294967295 pid=583 comm="sudo" exe="/usr/bin/sudo" sig=11 res=1 g_hash_load_feeds: pkg_hash_load_status_files: pkg_vec_insert_merge: Adding new pkg=software_suite version=1.0.0 arch=arm. pkg_info_preinstall_check: Updating file owner list. pkg_info_preinstall_check: Updating file owner list. Segmentation fault ``` [1] https://groups.google.com/g/opkg-devel/c/yydLk9_mS68
REPRODUCTION NOTE. I haven't had success reproducing this in my opkg dev environment (Intel x64), nor on an x64 virtual machine with a more substantial opkg environment. So at this time, I expect this error is limited to ARM32 systems. The next action here is for someone to confirm the bug on a second ARM32 system, and probably grab a stacktrace of the context in which the SEGFAULT is thrown.
Created attachment 4971 [details] opkg.bin opkg binary used in reproduction
Comment on attachment 4970 [details] test_example.ipk Example IPK which has been used when reproducing the bug.
Ashlin grabbed this gdb stacktrace of the error. ``` Program received signal SIGSEGV, Segmentation fault. 0xb6e920d4 in strlen () from /lib/libc.so.6 (gdb) where #0 0xb6e920d4 in strlen () from /lib/libc.so.6 #1 0xb6f7b7b8 in xlstat ( file_name=0x1f18dfa <error: Cannot access memory at address 0x1f18dfa>, st=0xbec3daf0, st@entry=0xbec3dae8) at file_util.c:49 #2 0xb6f7b8dc in file_is_dir (file_name=<optimized out>) at file_util.c:80 #3 0xb6f748f8 in pkg_info_preinstall_check () at pkg.c:1443 #4 0xb6f83550 in prepare_upgrade_list (head=0xbec3dbb4, head@entry=0xbec3dbac) at solvers/internal/opkg_upgrade_internal.c:207 #5 0xb6f82efc in opkg_solver_list_upgradable (num_pkgs=num_pkgs@entry=0, pkg_names=pkg_names@entry=0xbec3dd9c) at solvers/internal/opkg_action.c:253 #6 0xb6f6a0b4 in opkg_list_upgradable_cmd (argc=0, argv=0xbec3dd9c) at opkg_cmd.c:686 #7 0xb6f6a538 in opkg_cmd_exec (cmd=0xb6f9e090 <cmds+140>, argc=0, argv=0xbec3dd9c) at opkg_cmd.c:1310 #8 0x004a1ec8 in main (argc=2, argv=0xbec3dd94) at opkg.c:473 ``` My interpretation is that this bug is an issue with the internal solver, where it will sometimes hand malformed filepaths to the xlstat() function. I asked Ashlin to enable the libsolv backend and attempt reproduction. That seems to have resolved the issue. So I'm marking this bug as internal-solver-only.
Hey there. I also run into a SegFault on list-upgradable. 0.6.2 built by buildroot for an arm64 target (also an RPI CM4 Module). After trying to trace this down further I came to the following chain of events: "file_hash_set_file_owner" called from "pkg_info_preinstall_check" messes up the file_name pointer when calling "file_list_remove_elt", effectively messing up installed_file->path and finally causing the segfault. Not sure if this is directly related here but I have a feeling it might be. Hope this helps, let me know if you need more details or you can explain the issue so I can patch it for this version.