#23 zbarcam does not exit cleanly on error

[Jarek Czekalski]

When zbar_processor_init fails (for example after not finding compatible video format), it immediately does return from the main function. I guess zbar_processor_destroy should be called before return. I submit a patch for just one return that was causing fatal error during one of my test runs.

What with the other returns?

[Jarek Czekalski]

patch

[spadix]

> I guess zbar_processor_destroy should be called before return

If the application is exiting, it really shouldn't matter. It is considered "cleaner" to always call destroy after create returns non-NULL, but generally only useful for leak testing.

> one return that was causing fatal error during one of my test runs.

That indicates an underlying problem. We need to understand what this fatal error is and why it goes away if the processor is destroyed before exiting...

[Jarek Czekalski]

A theoretical answer:

zbar_processor init makes 2 dangerous things:
1. spawns a new thread - this thread uses resources allocated by the main thread, so I conclude it should end before the main thread exits
2. allocated global system resources, video driver - it's better to free it before exiting or I can imagine the resource is infinitely locked if the driver is not able to clean itself

A practical one:
With VfW if no compatible format is found, zbar leaves its video thread active and capture driver connected while returning from main. That gives a similar effect as I was correcting in "fix vfw cleanup - DestroyWindow" thread ( https://sourceforge.net/tracker/?func=detail&aid=3363402&group_id=189236&atid=928517 ). I consider it this underlying cause.

Maybe instead of:

return(zbar_processor_error_spew(proc, 0));

we should call:

return(clean_and_error_spew(proc,0));

This clean_and_error_spew would call zbar_processor_destroy before error_spew. In all three cases. This work is inside zbarcam only.