Survex 1.1.6 "report to authors" bug

[Andy Waddington]

On Friday 2006-02-03 15:44, Mark wrote:

> How is the program supposed to know that the fault has ever been
> reported, and that it is indeed the same fault?

When a fault is reported that generates a "please report to authors"
message, and it is reported to the authors, one assumes that the authors
investigate and come to a conclusion as to what causes it. They can then
fix it, if it is fixable, or report it to some upstream project like wxwidgets
if it is outside their scope. In order to avoid having the same fault
reported repeatedly, wasting the authors' time and no doubt trying their
patience if it is something they can do nothing about, one would assume
that the athors would try to find a workaround, or at least put in some
code to check whether the conditions were right for this fault to occur,
and send a message _not_ asking for the user to report to the authors
but saying something more like "aven cannot work on a system without OpenGL
as wxwidgets (an external package used by aven) requires it".

I'm presuming that the authors of survex are familiar with the API of
the packages they use, but not the internals, meaning it would be less
work to interrogate the system to know whether a known fault would
manifest, than to go into the external package and fix the problem.

Olly's reply seems to imply that the facility to do this doesn't exist
in the API in question and that the granularity of your calls into the
API are too coarse to be sure that a segfault was indeed due to this
specific cause, so that you prefer to be told of the fault repeatedly
rather than miss a possible unknown fault. That seems sensible in the
circumstances, but it does surprise me in that you seem to be able to
diagnose that the message is caused by a bug in wxWidgets from a lot
less information than I would imgaine would be available to the code.

Olly's earlier reply seemed to imply that it's not possible to do these
tests before wxWidgets segfaults, as there is no method of reporting
to the user. That's a factor that hadn't originally occurred to me,
as the toolkit I use (FLTK) gives you plenty of opportunity to do things
before calling the core routine whihc starts a polling loop and opens
windows. I had assumed that wxWidgets would also give you the chance to
do various startup tests before getting to the stage where it might
bomb out. That was the same logic I was employing when suggesting that
"aven --help" or "aven -v" might be useful ...

> Besides, how many times the fault is reported is nothing to do with the
> original issue as to where it came from in the first place.

how many times the fault is reported has a lot to do with how many times
the authors have to deal with email reporting it ... readers of this list
would no doubt not report a fault that they had recently seen explained
on the list, but if you are getting reports from users that aren't on the
list, I would have thought that it would become an issue on the authors'
time.

On the other hand, maybe it is more valuable to have a list of people
who have observed the fault whom you can ask to test if, in due course,
a fix is believed to have been done.

I have found (from both ends of the reporting chain), that people grow bored
with reporting faults if they constantly meet with "oh, that's a known
problem we can't fix", and it's worth making strenuous efforts to save
such users' effort for faults you don't know about... It's better to
have the program spot the upcoming conditions for a fault than to rely
on users browsing a "known fault" database, as so few users manage to
actually find the same problem in such a database (about three in four
faults I've reported into bugzilla systems have turned out to be known
faults described in such a way that none of my keyword searches have
spotted them).

Andy