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 <stepharo.s...@gmail.com> 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


Reply via email to