After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 547297 - Crash reading zip/7za files with 7z version 4.55
Crash reading zip/7za files with 7z version 4.55
Status: RESOLVED FIXED
Product: file-roller
Classification: Applications
Component: general
2.23.x
Other All
: Normal critical
: ---
Assigned To: Paolo Bacchilega
file-roller-maint
Depends on:
Blocks:
 
 
Reported: 2008-08-11 14:29 UTC by Matt Keenan (IRC:MattMan)
Modified: 2008-08-12 18:28 UTC
See Also:
GNOME target: ---
GNOME version: 2.23/2.24


Attachments
Patch (961 bytes, patch)
2008-08-11 14:30 UTC, Matt Keenan (IRC:MattMan)
none Details | Review

Description Matt Keenan (IRC:MattMan) 2008-08-11 14:29:56 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
Comment 1 Matt Keenan (IRC:MattMan) 2008-08-11 14:30:54 UTC
Created attachment 116350 [details] [review]
Patch

Check the full_path for NULL before adding the fdata.
Comment 2 Paolo Bacchilega 2008-08-11 16:34:44 UTC
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?
Comment 3 Matt Keenan (IRC:MattMan) 2008-08-12 13:45:00 UTC
Paolo, thanks for the quick response, I tested your latest update to trunk and
it works a treat.
Comment 4 Paolo Bacchilega 2008-08-12 18:28:15 UTC
ok, closing as fixed...