What is the craziest bug you ever face

When I was developing a new Morphic layout policy (in Squeak before there was Pharo, but I imagine it still applies), I found numerous bugs relating to bounds and layout methods and the order they get called in various circumstances; bounds & layout is a poorly documented, fragile part of Morphic.  It was a long time ago, so I have forgotten the details, but periodically, something I wrote for my layout would add or trigger one of these bugs, the entire GUI would stop working, and I would be left with the emergency debugger.  I didn't & probably don't have enough skill with the emergency debugger to debug order & layout issues in objects I can no longer see, so I would roll back my latest change & keep working blind, trying to guess what went wrong.  Of course if you get the emergency debugger, you can't see anything that was in the Transcript either.

I vaguely recall making a lot faster progress after finding a way to put a conditional halt in the layout methods, so more of the time, I could have only that object be messed up while I stepped through what was happening.  I don't know about concepts, but two actual tools that might have helped (and for all I know, existed but I didn't/don't know about them):
- Some kind of sandbox like projects, where changes apply to some subset of objects first, before you roll them out to all objects.  But, to help in this case, it would have to allow display of objects from multiple "projects" in the same world, so that the debugger would still work if bounds calculations were messed up for the test objects.
- A message passing visualizer that could show an animation of a conversation log among  collaborating objects.  You could give it a couple of objects and classes to start with, and it could show instance variables that are likely to indicate relationships as well as a sequence of messages that were passed.  To see what you wanted, you could hide specific messages, or unhide specific messages, or zoom in on a specific moment.

It's changing the topic a little (since dealing with security bugs is part of what I do, they aren't difficult or unusual for me), but from a security perspective, it seems to be difficult for developers to understand and (for Smalltalk developers especially) believe the security bugs they write.  These bugs may not result in functionality problems until the code is attacked.  It would be good for the community if we had a visual taint tracker.  This could help people see injection vulnerabilities, which seem to be the most often disbelieved.  When you inspect an object, you could see e.g. which data came directly from the network.  To change the data from red to green, you would need to validate it in some way, or (dangerously) mark data sources as trusted.  We would need a taint tracking infrastructure to make this possible, so it would be a substantial project, but e.g. perl (of all languages) has had that part for 20 years.  Telling a tool where you think your validation perimeter is, or which instance variables you are trusting, would be especially neat, since if you saw tainted data inside that perimeter, you would know you had a problem.

Ah, so easy to wave ideas around, so much more work to actually implement them.  :/

Brenda

> On Mar 9, 2017, at 5:36 AM, Stephane Ducasse <[hidden email]> wrote:
>
> Hi guys
>
> During the DSU workshop we were brainstorming about what are the most difficult bugs we faced and what are the conceptual tools that would have helped you.
>
> Stef