[Foxlit]

It's great that the taint log is now more verbose about tainted table fields. The next logical step would be to also include tainted local variables.

Setting taintlog to 11 outputs additional messages to taint.log whenever a table field is tainted, following the same format as taintlog 2 (and erroneously claiming that the variable was global):

1/29 15:40:00.002  Global variable foo tainted by FooAddon - Interface\AddOns\FooAddon\File.lua:30

and when a tainted table field is read:

1/29 15:40:00.004  Execution tainted by FooAddon while reading name - Interface\FrameXML\OptionsFrameTemplates.lua:80 OptionsList_DisplayButton()
      Interface\FrameXML\InterfaceOptionsFrame.lua:184 InterfaceAddonsList_Update()
      Interface\FrameXML\InterfaceOptionsFrame.lua:629 InterfaceAddonsList_AddCategory()
      Interface\AddOns\FooAddon\File.lua:42

While this is nice, any taint problem is 90% solved (or at the very least identified) once you have a found a concise and reliable way to reproduce it -- the rest is just about reading enough FrameXML code to understand what's going on. Ultimately, a huge log file (and one only available on the PTR) is less helpful in debugging occasional problems people encounter on live realms.

A better long-term fix would be to allow the client to (optionally) store taint history* alongside the taint flags, and backtrace through that history whenever a protected function is called from a tainted execution path. This would produce a taint trace that would be about as helpful as an ordinary stack trace is to diagnosing an ordinary error.


* More specifically, the execution should remember why it was tainted (which tainted variable was read, and why that variable was tainted), and all variables should remember why they were tainted (which variable tainted the execution when they were written, and why that variable was tainted).

Originally Posted by spiel2001 The UI team also made some changes to how taint is reported in the hopes that there will be fewer instances of misreported taint (the wrong addon getting blamed, etc.). These changes should appear over on the production servers when 5.2 goes live.

What exactly are those changes? I'm still under the impression that if your addon appeared in a taint error, it is as a consequence (albeit a potentially remote one) of code included in your addon.