On 6/7/07, Viktor Griph <[EMAIL PROTECTED]> wrote:
On Wed, 6 Jun 2007, [EMAIL PROTECTED] wrote:
> I can't understand why module points into a freed region of memory
> here. The single list searching loop seems correct at the first glance.
The problem is that module_receive and FlushMessageQueue will destroy the
module structure on IO failiure (modules closing down). I've committed a
simple fix for that particular loop, but there might be other similar
cases, which I can't check for right now.
I believe there's an issue with the input data mechanism. When a
module gets killed its input data may still be in the input queue,
which means that there is a pointer laying around that may point to
"nowhere land".
Some time ago I restructured the input mechanism in a more "OO"
fashion, but the underlying event sequence remained the same.
Obviously that sequence it is not adequate to the new module list
mechanism, so it needs to be rethinked.. I was wanting to do that some
time ago, but real life got in the way... Anyway, I'm having semester
exams at university, so I may dedicate some time to fvwm - a paradox,
I know :) .
A better fix would be to make FlushMessageQueue and module_receive and
possible others, not kill the bad modules, but to move them to a death row
to be killed at a safe point.
There was a similar issue, with the startup modules. Dominik solved
that by adding a flag to the module struct. Maybe this could be solved
the same way, by flagging the modules instead of killing them, so they
would get killed in a safe place.
There's another approach that was in my mind before Dominik's fix: to
have several module lists and one universal set of functions for
handling them. This way there could be one list for the startup
modules, other for the normal ones and other for the "malfunctioning"
modules.
This scheme could be extended to support list broadcasts - several
"normal" lists, each one being one broadcast domain. This could also
somewhat replace the current mask hacks: sync modules in one list
while async in another, for instance.
I would like to hear your opinions on this..
Cheers,
Renato
