Corruption in hooks; hooks not triggering

[Nick C]

I wonder if there is some sort of corruption going on in hooks' internal tables. I first noticed the symptoms a couple of months ago (sorry, can't be definite on which dev release number), and maybe it is two bugs manifesting as one.

Symtoms:
The main symptoms are that 1) hooks appear to stop triggering, and 2) that the "show hooks" command outputs garbage or unknown hooks.

1) This one appeared a couple of commits ago: hook appears to never get called. For example, I've always had in my musca config file the hook "hook on ^(add|use) pad 0 0 15 0" to make a small border at the top for a status bar from dzen2. For several weeks now, it seems this hook never gets called as I have to manually run the pad command if I create a new group or if I switch to one that is created on startup but that I haven't used yet (i.e. the bug exists both for startup groups in a new session and for user-created groups in an existing session).

2) This one has been present on and off since I first started using dev, about mid-june. It didn't show itself for a few weeks around early July, but has reappeared in the last few weeks.

After some time in a session, the hook event table appears to become corrupt, as 'musca -c "show hooks"' outputs odd characters for the trigger, e.g "hook on x+ [new line plus undisplayable char] exec kill -usr1 3906". (The odd chars may not necessarily accurately show the state of the internal table since the tty might not be able to display properly the chars that musca -c "show hooks" is sending.) In this example, I don't know what "x+{garbage}" is, but it isn't anything I have set up.

I use hooks to change the state of a status bar script and dynamically create and remove them according to the script. I use them to send a signal to a process whenever I switch groups . The code in a bourne shell script is: $MUSCA -c 'silent hook on ^use exec kill -usr1 '"$$", where $$ is the script's PID. If the script dies, an EXIT trap removes the hook. Somehow, somewhere, the hooks are being corrupted. Also, once I start to see the undisplayable chars in the output of the "show hooks" command, I start to save my work because previous experience suggests that musca is going to crash sooner rather than later (not to imply that it crashes often).

Suggestion: provide a method to remove all hooks. If a hook trigger is corrupted, you can't type in the chars that are needed for musca -c "hook off {chars here} command-to-execute" to remove the hook so it can't be removed.

Sorry for the vague nature of this report; it's one of those things easy to see that there is oddness, but hard to describe.

Nick

[Sean Pringle (sean-pringle)]

May I have a copy of your scripts and .musca_start? I'd like to try and reproduce this, then analyze musca with gdb. Thanks.

[Nick C (ncoleman-internode)]

On Mon, 21 Sep 2009 04:56:32 -0000
Sean Pringle <email address hidden> wrote:

> May I have a copy of your scripts and .musca_start? I'd like to try and
> reproduce this, then analyze musca with gdb. Thanks.
>

Thanks for looking at this. I'm in Perth, Western Australia, GMT-8, if you
need to get in touch. I attach status_bar.sh and .musca._start. I'm
currently using the latest stable release, 0.9.23. I was using the dev
version, but switched back after some problem that I forget now, I think it
was mplayer not working even with -vo sdl, but don't hold me to that.

THE PROBLEM

Since I wrote those comments in the debug report, I've realised I didn't
understand musca that well. Correct me if I'm wrong on these, as I almost
certainly will be, but it may help to stop you chasing red herrings. These
comments are all made from looking at evidence from the perspective of
outside the black box, so they're uninformed with regard to musca's internals.

The disappearing hooks comment perhaps isn't a bug, but instead I wonder if
musca grabs the first regex it finds and stops looking at subsequent hooks
in the list. Also, I think that new hooks are added to the beginning of the
list. Therefore, if you add a hook that uses the same regex as another hook,
only the hood you added will get executed.

That would explain why "hook on ^use pad 0 0 15 0" doesn't work, it simply
never gets called because musca sees the "hook on ^use...." that
I've added subsequently, executes that hook and stops searching.

However, the corruption on the hood command "table" does appear to be
genuine. Right now `musca -c "show hooks"` produces
 hook on ^use exec kill -usr1 16471
 hook on exec kill -usr1 16028
 hook on ^(add|use) pad 0 0 15 0
pid 16471 is my currently running status_bar.sh, 16028 is non-existent,
and you'll note that the second hook doesn't have a visible regex, but does
have a space before the exec (non-displayable chars perhaps?).

UPDATE
I wonder if there is some recursion happening. While checking the script
before mailing it to you and trying to remove the above odd hook, I somehow
managed to change the hook to:
hook on show hooks exec kill -usr1 16028
Notice that somehow I've added "show hooks" into the regex for the existing
hook. Then, subsequent attempts to change and then display hooks produced
this:
 hook on show hooks exec kill -usr1 16028
 hook on show exec kill -usr1 16028
 hook on show hooks exec kill -usr1 16028
 hook on XÁó·È³h exec kill -usr1 1602
so you can see that running "musca -c "show hooks"" actually ended up changing
the hook table and eventually corrupting it.

SCRIPT

Status_bar.sh uses the ash shell; if you don't have that it will work fine
under the sh shell, just change the shebang statement at the start of the
script.

Normally, status_bar.sh uses dmplex (utility included with dzen2 to write to
a certain position, or field, within the dzen2 output) and dzen2. Dmplex
listens on a socket and passes output to dzen2. The first digit in the
output is the field number.

For musca, the idea is that whenever the user switches groups, musca sends
the script a USR1 signal. The script traps the signal and executes a
f...