Comment 18 for bug 1566050

Created attachment 124413
patch to look for leaked VclPtrs at the end of DeInitVCL

Some VclPtrs leak past the end of DeInitVCL, which is unfortunate as they might still be subject to callback and assume VCL to be alive.

Applying the attached patch and running:

 make subsequencheck; find workdir/JunitTest/ -name '*log'|xargs grep LEAK|sed -e 's/^.*LEAK/LEAK/'|sort|uniq -c

result in:

      1 LEAKED VCLPTR: P10SfxPrinter refered to from a PK6VclPtrI10SfxPrinterE
      1 LEAKED VCLPTR: P12OpenGLWindow refered to from a PK6VclPtrI12OpenGLWindowE
     27 LEAKED VCLPTR: P12OutputDevice refered to from a PK6VclPtrI12OutputDeviceE
     14 LEAKED VCLPTR: P13VirtualDevice refered to from a PK6VclPtrI13VirtualDeviceE
      2 LEAKED VCLPTR: PN3vcl6WindowE refered to from a PK6VclPtrIN3vcl6WindowEE
      1 LEAKED VCLPTR: PN5chart11ChartWindowE refered to from a PK6VclPtrIN5chart11ChartWindowEE

It would be good to have all those eliminated and explicitly have them set to nullptrs deterministically in DeInitVCL (or earlier).

Additional notes:
- Some VclPtr have a vptr of NULL while still alive, which is discomforting in itself
- Doing a build with the patch and e.g. playing through MozTrap testcases manually to find well-reproducable leaks likely is a nice EasyHack