Red Hat Bugzilla – Bug 76708
lha fails with segm fault on any file archiving
Last modified: 2007-04-18 12:47:56 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)
Description of problem:
trying to do:
lha a archive SomeFile
I receive segmentation fault in lha.
Stack backtrace is:
#0 cleaning_files (v_filec=0x60000000000027b4, v_filev=0x6000000000002798) at
#1 0x400000000000b620 in cmd_add () at lhadd.c:523
#2 0x4000000000003820 in main (argc=4, argv=0x80000fffffffb748) at lharc.c:289
Problem is that you guys use malloc/xmalloc routines in src/lharc.c implicitly,
i.e. without prototyping. Declared implicitly, int return type for function is
assumed, while void * is needed. As int is only 32 bits width while void * is
64 bit width on IA64, result from malloc is cut to 32 bits to fit in int. As a
result bad pointer produced and any dereferencing of it causes segmentation
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. echo > SomeFile
2. lha a archive SomeFile
Actual Results: Segmentation fault (core dumped)
Expected Results: archive archive.lzh in current directory
gcc warns about pointer truncation compiling source:
lharc.c: In function `main':
lharc.c:256: warning: cast to pointer from integer of different size
lharc.c:264: warning: cast to pointer from integer of different size
lharc.c:270: warning: cast to pointer from integer of different size
You could pay attention to it testing the application (if you have done it at
all of course).
Workaround to get more workable lha is to include <stdlib.h> to lharc.h file.
By the way gcc still warns about pointer truncation in another source files -
you should pay attention to it too.
it should not use malloc routine from src/lharc.c. it seems that the lha-1.14 is
fixed in RHL 9. I will do errata soon.