Comments (3)
mainroach
commented on May 2, 2024
Can you provide your input argument that causes the crash in ptrOutputDir ?
from etc2comp.
jclee
commented on May 2, 2024
For what it's worth, I'm encountering the same bug when running etctool under Ubuntu Precise. It's a memory error, so reproducing it in any given environment is probably going to be difficult. But in my specific case, I've observed the failure as a tripped malloc() assert for certain output path formats. For example, this output path containing a directory name of exactly 23 characters reproduces the crash for me, while directories of other lengths (tried 4-36) do not:
./etctool data/00007.png -output out_xxxxxxxxxxxxxxxxxxx/00007.ktx
etctool: malloc.c:2372: sysmalloc: Assertion `(old_top == (((mbinptr) (((char *) &((av)->bins[((1) - 1) * 2])) - __builtin_offsetof (struct malloc_chunk, fd)))) && old_size == 0) || ((unsigned long) (old_size) >= (unsigned long)((((__builtin_offsetof (struct malloc_chunk, fd_nextsize))+((2 *(sizeof(size_t))) - 1)) & ~((2 *(sizeof(size_t))) - 1))) && ((old_top)->size & 0x1) && ((unsigned long) old_end & pagemask) == 0)' failed.
A gdb stacktrace shows the failure occurs in lodepng_realloc() at third_party/lodepng/lodepng.cpp:73, although I'm pretty sure there's nothing wrong with lodepng.cpp -- it's just fallout from the buffer overrun in EtcTool.cpp.
The corruption is reliably detected by valgrind for any input:
valgrind etctool data/00007.png -mipmaps 100 -format RGBA8 -effort 50 -output out/00007.ktx
[...]
==47421== Invalid write of size 1
==47421== at 0x434BC6: Commands::ProcessCommandLineArguments(int, char const**) (EtcTool.cpp:656)
==47421== by 0x4335D2: main (EtcTool.cpp:139)
==47421== Address 0x5c3a178 is 0 bytes after a block of size 24 alloc'd
==47421== at 0x4C2B800: operator new[](unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==47421== by 0x434B97: Commands::ProcessCommandLineArguments(int, char const**) (EtcTool.cpp:654)
==47421== by 0x4335D2: main (EtcTool.cpp:139)
==47421==
==47421== Invalid read of size 1
==47421== at 0x58C0943: vfprintf (vfprintf.c:1661)
==47421== by 0x58E58FA: vsprintf (iovsprintf.c:42)
==47421== by 0x58C9506: sprintf (sprintf.c:32)
==47421== by 0x435176: CreateNewDir(char const*) (EtcTool.cpp:821)
==47421== by 0x434BD4: Commands::ProcessCommandLineArguments(int, char const**) (EtcTool.cpp:657)
==47421== by 0x4335D2: main (EtcTool.cpp:139)
==47421== Address 0x5c3a178 is 0 bytes after a block of size 24 alloc'd
==47421== at 0x4C2B800: operator new[](unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==47421== by 0x434B97: Commands::ProcessCommandLineArguments(int, char const**) (EtcTool.cpp:654)
==47421== by 0x4335D2: main (EtcTool.cpp:139)
[...]
Per @spearx 's suggestion, I am able to fix both the valgrind output and the malloc assertion by expanding the buffer by one to accommodate the null terminator, on the following line:
https://github.com/google/etc2comp/blob/e2e733c/EtcTool/EtcTool.cpp#L654
from etc2comp.
bonizz
commented on May 2, 2024
I agree with @spearx and @jclee, it looks like an off-by-one error.
The allocated size of the buffer is of size c, but ptrOutputDir[c] is one past the size of the buffer.
ptrOutputDir[c] = '\0'; writes a 0 past the allocated buffer.
Either ptrOutputDir[c-1] = '\0'; (to trim the trailing slash) or ptrOutputDir = new char[c+1]; should fix.
Edit: test case is to have an output file with a slash (dir separator) in it
from etc2comp.
Related Issues (20)
- Make sure Colt McAnlis properly reads issues before closing them HOT 16
- Block should not know Image
- Which format? HOT 1
- Compressing normalmaps HOT 1
- Not all mipmap levels are generated for non-square images HOT 3
- -output flag not handling paths with spaces HOT 1
- Hardcoded include paths that do not make sense in windows
- PNG and EAC_RG11 support HOT 2
- how to improve compression speed HOT 5
- Default number of jobs is not correct
- Compressing small images (8x8 px png file)
- Mipmaps as input other than generating automatically
- assert() abort with ETC2A1 & RGBX
- Math-related error while building with vcpkg
- Near-infinite compression time on some textures. HOT 2
- Arm64 support
- EtcTool encoded sRGB(A) textures don't match source PNG. HOT 3
- R11 and RG11 seem to be computing data as 8-bits instead of 11-bit data.
- How to output pkm? HOT 1
- Memory leak of m_paucEncodingBits in Etc::Image HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from etc2comp.