Node.js childprocess .kill for an ffmpeg shim kills the shim, but not the actual ffmpeg instance

[MisterD123]

Hi,

after an hour of tracking this weird behavior I think I have it narrowed down to this shim thing that the chocolatey ffmpeg install apparently sets up? I'm not familiar with how that works, I can imagine it may also be that the ffmpeg package in chocolatey has the shim generator misconfigured. In any case, the behavior is as follows:

when i execute a ffmpeg command, it spawns two ffmpeg.exe processes: the PID that the command creates refers to a process labelled "ShimGen generated shim - shim", and judging by resource utilization, the other instance is what does the actual processing. Now when I go to kill the PID that was created by the command (alternatively, force-exit the shim process in the task manager), the shim is killed and my shell returns me to the command prompt to enter the next command, thinking that the ffmpeg process has exited. However, ffmpeg continues to run and process stuff, and continues to write stdout/stderr into my shell window.

I would argue that killing the shim process should also always kill the underlying child process that the shim is redirecting to? Independently of what's the proper way to fix this, is there something I can do in my local system configuration to work around this issue until it is hopefully properly fixed, so that killing the PID that is returned by an ffmpeg command will also kill the actual ffmpeg instance running behind the shim?

┆Issue is synchronized with this Gitlab issue by Unito

[scordio]

Thanks for reporting it, @RainerGanss. The assertions generator projects have been neglected due to lack of capacity, but we'll do our best to refresh them.

Just to make sure we aim for the right target, how are you using the assertions generator? Is it via the Maven or Gradle plugin?

[RainerGanss]

Hi @scordio,

I am using the maven plugin. I am right now customizing the code generation via the templates to avoid the call to the internal API.

Thx for the quick response. Once I am done with the template fiddling I'll attach it here for other fokes. It's not pretty though...

[RainerGanss]

my_has_elements_assertion_template_for_iterable.txt

I replaced the calls to the internal API with public ones that I hope do the same...

I spent many hours yesterday trying to get this to work and on that journey encountered serveral severe bugs in this plugin. I am migrating more than a dozent projects to java 17 and the hacks I had to make to get this to "work" are unbearable.

For that reason I have decided to completely remove generated assertions from all my projects. Sad to see this project die...

[scordio]

The usage of the internal API is also something we faced with assertj-guava and refactoring is ongoing to avoid it.

The same strategy could be applicable also for the assertions generator.

[joel-costigliola]

I still like the assertion generator but indeed we have not the capacity to really maintain it. The issue seems related to the java module, a combination of the generator using internal stuff (which is bad) and assertj-core not exporting them.

[RainerGanss]

I loved the generator used it widely. For now I will run it one last time, hack the hell out of the code to get it work with java > 9, check it in under src/main and will either migrate away from the plugin completely or wait and hope that it gets fixed.

In case you wanna give the plugin some love, here are some other issues:

• In the documentation here https://joel-costigliola.github.io/assertj/assertj-assertions-generator-maven-plugin.html#custom-templates for assertionClass the closing tag is missing the /
  • In general is the complete type definition for TemplateType missing in the plugin.xml -> no auto completion in the IDE
• Both entryPointClassPackage and generateAssertionsInPackage are broken if the model is not in one package and has inter-package dependencies (imports are missing and return types are wrong in the Assertions and SoftAssertions classes.

In general it would be great if the generator + the maven/gradle plugins would specifically be targeted to run in projects > 9. There is a lot more to be considered... It took me 6 hours and plenty of hacks just to get it compiling - let alone executing tests based on those assertion classes.

Cheers guys, Rainer

[scordio]

@joel-costigliola I would also evaluate merging all the generators in a Maven multi-module, it could simplify the overall maintenance