[00:17] *** kjp left
[00:20] *** kjp joined
[00:34] *** MasterDuke joined
[00:48] *** MasterDuke left
[09:25] *** lizmat_ left
[09:26] *** lizmat joined
[10:10] *** ilogger2 left
[10:10] *** ilogger2_ joined
[10:57] *** librasteve_ joined
[16:35] <timo> TIL the Ball-Larus algorithm

[16:35] <timo> https://github.com/Sap4Sec/path-aware-fuzzing/blob/main/paper/preprint.pdf

[16:42] <timo> this paper has a pretty cheap way to enumerate different paths that control flow can take through a function

[16:42] <timo> it terminates at back-edges and in this paper specifically they also cut off paths that hit function calls, though I believe this is not a requirement to use this algorithm

[17:24] <timo> there's a little bit of prior art about path profiles for "statistical debugging" that was a little interesting (HOLMES from microsoft or something) but I think that relies upon a very very large and active installation base before it gets useful

[17:25] <timo> but for actual manual debugging it could be interesting to be able to always see the path through the bytecode that your local function took most recently?

[18:02] <lizmat> yes!

[18:03] <timo> the most important thing is that it doesn't make running stuff normally 10x slower :)

[18:04] <timo> you could say "only turn the feature on when you need it" (on top of only being turned on when moar is in debugserver mode already) but usually you only know that you need it after it's too late to turn it on :)

[22:57] *** MasterDuke joined
[23:53] *** MasterDuke left