GNOME Bugzilla – Bug 547297
Crash reading zip/7za files with 7z version 4.55
Last modified: 2008-08-12 18:28:15 UTC
Steps to reproduce: 1. Ensure verison of 7z on your system is < 4.57, e.g. 4.55 2. Create a 7z zip file with file-roller. 3. File roller crashes when trying to read the contents of the zip file. Stack trace: core 'core' of 15768: ./file-roller /tmp/file-glade.7a fee8327e strcmp (0, 848e7e0) + de 080bc59b sort_by_full_path (8487000, 8487014) + 2b fee815ea qsort (8487000, b, 4, 80bc570) + 39a fed8a835 g_ptr_array_sort (848b2b0, 80bc570) + 29 080be62d fr_window_update_file_list (8188000, 1) + 2bd 080ca459 fr_window_go_to_location (8188000, 81ba988, 1) + 159 080c1e13 action_performed (8178de0, 3, 8178e58, 8188000) + 353 080dc24a fr_marshal_VOID__INT_POINTER (81895c8, 0, 3, 8465aa0, 804714c, 0) + ba feb4f3eb g_closure_invoke (81895c8, 0, 3, 8465aa0, 804714c) + 107 feb64fda signal_emit_unlocked_R (8189dd0, 0, 8178de0, 0, 8465aa0) + 7b2 feb642db g_signal_emit_valist (8178de0, 6f, 0, 8047328) + 873 feb64415 g_signal_emit (8178de0, 6f, 0, 3, 8178e58) + 25 080a0e12 action_performed (8183060, 3, 8178e58, 8178de0) + 282 080dc24a fr_marshal_VOID__INT_POINTER (848e520, 0, 3, 8465a60, 804740c, 0) + ba feb4f3eb g_closure_invoke (848e520, 0, 3, 8465a60, 804740c) + 107 feb64fda signal_emit_unlocked_R (8180c20, 0, 8183060, 0, 8465a60) + 7b2 feb642db g_signal_emit_valist (8183060, 60, 0, 80475e0) + 873 feb64415 g_signal_emit (8183060, 60, 0, 3, 8178e58) + 25 080a5594 fr_command_done (8178e28, 8183060) + 94 feb65755 g_cclosure_marshal_VOID__VOID (8189568, 0, 1, 81c0068, 80476bc, 0) + 55 feb4f3eb g_closure_invoke (8189568, 0, 1, 81c0068, 80476bc) + 107 feb64fda signal_emit_unlocked_R (8186e08, 0, 8178e28, 0, 81c0068) + 7b2 feb642db g_signal_emit_valist (8178e28, 76, 0, 804788c) + 873 feb64415 g_signal_emit (8178e28, 76, 0) + 25 080ba90d check_child (8178e28) + 39d fedb1584 g_timeout_dispatch (8485c08, 80ba570, 8178e28) + 24 fedaeb30 g_main_dispatch (812dc90) + 1e0 fedafc31 g_main_context_dispatch (812dc90) + 85 fedb004e g_main_context_iterate (812dc90, 1, 1, 8106f00) + 3ce fedb0650 g_main_loop_run (816be98) + 1b8 fe76e5ca gtk_main (feffb7dc, 810d838, 8047b14, 8047a80, 808e63a, 2) + b2 080d745e main (2, 8047a8c, 8047a98) + 14e 0808e63a _start (2, 8047b7c, 8047b8a, 0, 8047b9d, 8047c1d) + 7a Other information: Testing this on OpenSolaris, file-roller appears to be interpreting the start of lf 7z output slightly incorrectly for version 4.55 of 7z. e.g. if I create a 7z file containing the /usr/share/file-roller/glade directory the command to list the contents would be : $ 7z l -slt -bd -y -- /tmp/file-glade.7a | more 7-Zip 4.55 beta Copyright (c) 1999-2007 Igor Pavlov 2007-09-05 p7zip Version 4.55 (locale=en_IE.ISO8859-15,Utf16=on,HugeFiles=on,2 CPUs) Listing archive: /tmp/file-glade.7a Method = LZMA Solid = + Blocks = 1 ---------- Path = glade/add-options.glade Size = 5884 Packed Size = 6414 Modified = 2008-08-11 12:42:31 Attributes = ....A CRC = 670B34D1 Method = LZMA:17 Block = 0 Path = glade/batch-add-files.glade Size = 21165 Packed Size = Modified = 2008-08-11 12:42:31 etc etc etc When this is being processed by fr-command-7z.c : list__process_line() the first fdata structure to be added to the list is empty/NULL as a result when you attempt to sort the list for display, strcmp cores when trying to compare a NULL string. Solution is to simply check for non NULL full_path in this function before adding the blank fdata structure. I will file an attachment
Created attachment 116350 [details] [review] Patch Check the full_path for NULL before adding the fdata.
Maybe a dup of bug #545188. The problem is there are two list formats and it seems that version 4.55 uses the new format, I couldn't test version 4.55 because I didn't find a debian package for it. Anyway I changed the current trunk version to use new output format even with version 4.55. Can you test it, please?
Paolo, thanks for the quick response, I tested your latest update to trunk and it works a treat.
ok, closing as fixed...