potential problem? (z_stream initalization)
Hi, While debugging luatex, I ran into this warning from valgrind that seems to affect regular pdftex as well: ==4016== Conditional jump or move depends on uninitialised value(s) ==4016== at 0x80F851B: longest_match (deflate.c:1143) ==4016== by 0x80F9848: deflate_slow (deflate.c:1595) ==4016== by 0x80F8D98: deflate (deflate.c:790) ==4016== by 0x80DAE88: write_zip (writezip.c:58) ==4016== by 0x80729A2: pdf_flush (luatex1.c:10926) ==4016== by 0x80757BD: pdf_end_stream (luatex1.c:11068) ==4016== by 0x809AA68: zpdf_ship_out (luatex2.c:2057) ==4016== by 0x809C913: zship_out (luatex2.c:2770) ==4016== by 0x80A168B: handle_right_brace (luatex3.c:2431) ==4016== by 0x80A8D28: main_control (luatex3.c:2912) ==4016== by 0x805A796: main_body (luatexini.c:5910) ==4016== by 0x80AE866: main (luatexextra.c:378) (this is from luatex, but I get the same warnings for 1.40.1) It is a bit of a mystery to me what the right way to set up the z_stream is, so I thought I'd first ask if somebody else knows. Best, Taco
Hi Taco, On Fri, 26 Jan 2007, Taco Hoekwater wrote:
While debugging luatex, I ran into this warning from valgrind that seems to affect regular pdftex as well:
==4016== Conditional jump or move depends on uninitialised value(s) ==4016== at 0x80F851B: longest_match (deflate.c:1143) ==4016== by 0x80F9848: deflate_slow (deflate.c:1595) ==4016== by 0x80F8D98: deflate (deflate.c:790)
on the x86_64 linux i currently can't reproduce it, but remember seen it on i586 (and couldn't find the cause). Which valgrind --tool did you use? BTW, i changed writezip.c here so that intermediate deflateInit() calls would be replaced just by deflateReset(); and no intermediate deflateEnd(). Hope was that the then removed memory reallocations would speed it up. It works, but no speed gain. Regards, Hartmut
Hi, On Sat, 27 Jan 2007, Hartmut Henkel wrote:
BTW, i changed writezip.c here so that intermediate deflateInit() calls would be replaced just by deflateReset(); and no intermediate deflateEnd(). Hope was that the then removed memory reallocations would speed it up. It works, but no speed gain.
actually my 1st try was wrong, it never triggered deflateReset. Now it works, and summing over 10 compilations $ time pdftex pdftex-all.tex 2>&1 > /dev/null with object compression on i get the following time statistics: orig patch quotient --------------------------. real 90.633 90.809 0.998062 user 89.537 89.589 0.99942 sys 0.463 0.799 0.579474 so there isn't any noticable difference in real and user, but the sys time goes down to < 60 % by the patch, reproducible. What does this actually mean? Regards, Hartmut
On Sat, 27 Jan 2007, Hartmut Henkel wrote:
On Sat, 27 Jan 2007, Hartmut Henkel wrote:
BTW, i changed writezip.c here so that intermediate deflateInit() calls would be replaced just by deflateReset(); and no intermediate deflateEnd(). Hope was that the then removed memory reallocations would speed it up. It works, but no speed gain.
actually my 1st try was wrong, it never triggered deflateReset. Now it works, and summing over 10 compilations
$ time pdftex pdftex-all.tex 2>&1 > /dev/null
with object compression on i get the following time statistics:
orig patch quotient
ooops, it's patch orig quotient
--------------------------. real 90.633 90.809 0.998062 user 89.537 89.589 0.99942 sys 0.463 0.799 0.579474
so there isn't any noticable difference in real and user, but the sys time goes down to < 60 % by the patch, reproducible. What does this actually mean?
sorry, Hartmut
Hartmut Henkel wrote:
Hi,
On Sat, 27 Jan 2007, Hartmut Henkel wrote:
BTW, i changed writezip.c here so that intermediate deflateInit() calls would be replaced just by deflateReset(); and no intermediate deflateEnd(). Hope was that the then removed memory reallocations would speed it up. It works, but no speed gain.
actually my 1st try was wrong, it never triggered deflateReset. Now it works, and summing over 10 compilations
$ time pdftex pdftex-all.tex 2>&1 > /dev/null
with object compression on i get the following time statistics:
orig patch quotient --------------------------. real 90.633 90.809 0.998062 user 89.537 89.589 0.99942 sys 0.463 0.799 0.579474
so there isn't any noticable difference in real and user, but the sys time goes down to < 60 % by the patch, reproducible. What does this actually mean?
sys is the time spent in all system calls combined. Often, that is just I/O waits, but in this case I'd rather assume it is time spent in the bowels of malloc(). Taco
participants (2)
-
Hartmut Henkel -
Taco Hoekwater