New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Sharp Crash - libvips_42 - windbg - FAST_FAIL_FATAL_APP_EXIT #4041
Comments
A full stacktrace would be useful. PDBs to aid debugging are provided for the Windows libvips builds - you'll need the web-static version. https://github.com/libvips/build-win64-mxe/releases/tag/v8.15.2 I note you're using It also looks like the code in https://github.com/RyAndrew/amc-buddy/blob/main/app.js contains possible race conditions in the event there are concurrent requests with the same value for |
I'm not sure I understand the race condition. Express middleware determines if the thumbnail file exists and if not then generate a thumbnail. Afterwards execution is passed to the express static file server. It could be possible to request the same file simultaneously and I would expect that to lead to a more standard file access/locking error. I attempted to work around this bug by implementing the express-slow-down package. Thus allowing fewer simultaneous requests and adding a delay to subsequent requests. However I still experienced crashes. I was able to get windbg to output this after poking around a bit:
|
Thanks for the stack trace, the salient part is:
It looks like you're using an OpenSlide image as input and JPEG-2000 as output (the default for OpenSlide input IIRC). Neither of these formats are supported by the prebuilt binaries provided by sharp. Are you using the "all" variant from https://github.com/libvips/build-win64-mxe/releases/tag/v8.15.2 ? If so it's likely you've hit a problem in one of either the OpenSlide or OpenJPEG dependencies. |
I could not reproduce this using: PS> node -e "require('sharp')('316545457-c739f442-d1ed-45d1-83d2-3566c2ba8f30.jpg', { failOn: 'error' }).resize(450, 253).toFile('x.jpg')"
This may also indicate that the wrong PDB file has been loaded, you can verify this with: 0:000> !chksym libvips-42.dll
\\?\C:\Users\kleisauke\sharp-test\node_modules\@img\sharp-win32-x64\lib\libvips-42.dll
Timestamp: 65F30D45
SizeOfImage: 14B2000
pdb: /var/tmp/tmp-vips-web-x86_64-w64-mingw32.static.posix.web/vips-8.15.2.build_/libvips/libvips-42.pdb
pdb sig: 381B381D-4BA9-0BF8-4C4C-44205044422E
age: 1
Loaded pdb is C:\ProgramData\Dbg\sym\libvips-42.pdb\381B381D4BA90BF84C4C44205044422E1\libvips-42.pdb
libvips-42.pdb
pdb sig: 381B381D-4BA9-0BF8-4C4C-44205044422E
age: 1
MATCH: libvips-42.pdb and \\?\C:\Users\kleisauke\sharp-test\node_modules\@img\sharp-win32-x64\lib\libvips-42.dll |
Honestly I'm stabbing in the dark with this debugging process so any additional information is appreciated. I don't believe I'm trying to save anything as jpeg2000 but that appears to be the function name implicated in this dump file. Since this appears to be an issue with the upstream package my goal here would be to ensure I have the appropriate data to open an issue for them. Do you think there is anything additional to provide at this point? To generate this stack trace I used these files: This looks like I've got the correct symbols loaded - I would expect windbg doesn't load them if there is a mismatch.
|
@RyAndrew Does your app replace/override any of the prebuilt libvips binaries provided by sharp? By default sharp does not support the formats mentioned in the stack trace, which leads me to believe you have. However if you are using the "stock" binaries provided by sharp then I guess we might be seeing the effects of possible stack corruption on function pointers. Anything you can do to help narrow this down further, e.g. one image, one format, certain dimensions etc. would be helpful. Perhaps remove all networking logic and loop over files in a directory to see if you can still reproduce? |
Everything is stock - I replaced the DLL's with the static versions to capture the stack trace only. I'll try to produce a failure scenario with code - so far it has not been due to a specific file or anything like that. Your hint regarding specific dimensions is interesting - I'll test that as well. |
@RyAndrew Were you able to make any progress with this? |
Closing due to inactivity but please feel free to reopen with more details if further help is required. |
Possible bug
Is this a possible bug in a feature of sharp, unrelated to installation?
npm install sharp
completes without error.node -e "require('sharp')"
completes without error.If you cannot confirm both of these, please open an installation issue instead.
Are you using the latest version of sharp?
sharp
as reported bynpm view sharp dist-tags.latest
.If you cannot confirm this, please upgrade to the latest version and try again before opening an issue.
If you are using another package which depends on a version of
sharp
that is not the latest, please open an issue against that package instead.What is the output of running
npx envinfo --binaries --system --npmPackages=sharp --npmGlobalPackages=sharp
?What are the steps to reproduce?
run my program, generate a bunch of thumbnails, it will crash randomly
What is the expected behaviour?
not crashing
Please provide a minimal, standalone code sample, without other dependencies, that demonstrates this problem
I am running this code. https://github.com/RyAndrew/amc-buddy
It pulls images from email and it is crashing when I scroll through the web page and it generates thumbnails on the fly. It doesn't crash on a specific image, but it appears to be resource related in some way.
I tried adding sharp.simd(false) but that did not resolve the issue
This is the offending line performing the resize operation:
This line contains failOn:'error' because the images will sometimes have warnings.
Please provide sample image(s) that help explain this problem
Sample Image: https://github.com/lovell/sharp/assets/3945391/c739f442-d1ed-45d1-83d2-3566c2ba8f30
I captured a procdump but I couldn't figure out how to load the symbols into windbg
app.js-1.dmp
The text was updated successfully, but these errors were encountered: