[Bug]: GSlice: assertion failed: sinfo->n_allocated > 0

[KillerCodeMonkey]

Preflight Checklist

• I have read the Contributing Guidelines for this project.
• I agree to follow the Code of Conduct that this project adheres to.
• I have searched the issue tracker for a bug report that matches the one I want to file, without success.

Electron Version

24

What operating system are you using?

Ubuntu

Operating System Version

22.04

What arch are you using?

x64

Last Known Working Electron version

23

Expected Behavior

No errors when processing images (in parallel as well) with sharpjs like it is in electron v23

Actual Behavior

i am using sharpjs to transform images, randomly the app crashes with
GSlice: assertion failed: sinfo->n_allocated > 0

Testcase Gist URL

No response

Additional Information

I already asked at the sharp repo:
lovell/sharp#3384 (comment)

There i linked another github project with similar problems and how they solved it:
https://github.com/libvmi/libvmi/pull/927/files

So i do not know if this is a general electron issue or a combination when using both libs.

[github-actions]

Hello @KillerCodeMonkey. Thanks for reporting this and helping to make Electron better!

Would it be possible for you to make a standalone testcase with only the code necessary to reproduce the issue? For example, Electron Fiddle is a great tool for making small test cases and makes it easy to publish your test case to a gist that Electron maintainers can use.

Stand-alone test cases make fixing issues go more smoothly: it ensure everyone's looking at the same issue, it removes all unnecessary variables from the equation, and it can also provide the basis for automated regression tests.

Now adding the blocked/need-repro label for this reason. After you make a test case, please link to it in a followup comment. This issue will be closed in 10 days if the above is not addressed.

[VerteDinde]

Hey @KillerCodeMonkey, happy to look more into this - if you could attach a repro like the bot mentions above, or link to how you're using sharp in your own codebase, that would be awesome 🙂

[KillerCodeMonkey]

i will try my best to build an example to reproduce it.

[KillerCodeMonkey]

heyho, i invested some time and the root cause was the usage of graphql-upload library and not handline the createReadstream() in ALL cases. i had some condition so the graphql resolver so the stream was never read and that seems to lead to open streams until the memory is full.

but strange that this really occurs that fast with electron 24... but in the end. it was my fault :). Thanks

[Sandakan]

@KillerCodeMonkey How did you fix the crash?

[KillerCodeMonkey]

in the graphql part you need to read the readstream as the first thing you do in your resolver.
if you have some error handling before and return without reading the stream it stays open and there and will flood the memory it seems.

See: jaydenseric/graphql-upload#352 (comment)
or: flash-oss/graphql-upload-minimal#37 (comment)