Case which causes ImageDecodeBench to be ended with open file descriptor
Reported by
lysio...@gmail.com,
Jul 30 2017
|
||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.78 Safari/537.36 Steps to reproduce the problem: To reproduce bug please create empty.png which has size == 0 and run below command. Command: valgrind --track-fds=yes ./out/Default/image_decode_bench ~/Downloads/empty.png 1 What is the expected behavior? Have closed descriptor for passed file. What went wrong? Descriptor remains open. Did this work before? N/A Chrome version: 60.0.3112.78 Channel: stable OS Version: 6.1 (Windows 7, Windows Server 2008 R2) Flash Version: To reproduce bug please create empty.png which has size == 0 and run below command. Interesting part of output: ... ==5172== Open file descriptor 3: /home/mp/Downloads/empty.png ==5172== at 0x6937010: __open_nocancel (syscall-template.S:84) ==5172== by 0x68B9ACD: _IO_file_open (fileops.c:221) ==5172== by 0x68B9D34: _IO_file_fopen@@GLIBC_2.2.5 (fileops.c:328) ==5172== by 0x68ADD33: __fopen_internal (iofopen.c:86) ==5172== by 0x407B95: blink::(anonymous namespace)::ReadFile(char const*) (ImageDecodeBench.cpp:184) ==5172== by 0x407891: blink::Main(int, char**) (ImageDecodeBench.cpp:316) ==5172== by 0x408471: main (ImageDecodeBench.cpp:357) ... Look at https://cs.chromium.org/chromium/src/third_party/WebKit/Source/platform/testing/ImageDecodeBench.cpp?rcl=fc83d355527bf5b763e11338dcd642ff840179f4&l=193 There should be fclose(fp) before return: if (s.st_size <= 0) { fclose(fp); return SharedBuffer::Create(); }
,
Jul 31 2017
,
Feb 11 2018
,
Feb 12 2018
I'll just fix it. Thanks for the very detailed report. Sorry it got dropped. |
||||
►
Sign in to add a comment |
||||
Comment 1 by nyerramilli@chromium.org
, Jul 31 2017