Re: Does anyone use xterm on NetBSD/m68k 7.0?

[email protected] (Michael van Elst) writes:

>NetBSD/amiga 7.99.21, -current userland. xterm starts but no shell,
>the xterm apparently has forked and the child is in zombie state:

A full trace of xterm reveals that the child crashes immediately
when returning from fork() (and dumps core). The crash happens
in the fork wrapper in pthread_atfork.c when it tries to execute
callbacks as a child after returning from the syscall.

...
        ret = __fork();

        if (ret != 0) {
                /*
                 * We are the parent. It doesn't matter here whether
                 * the fork call succeeded or failed.
                 */
                SIMPLEQ_FOREACH(iter, &parentq, next)
                        (*iter->fn)();
                mutex_unlock(&atfork_lock);
        } else {
                /* We are the child */
                SIMPLEQ_FOREACH(iter, &childq, next)
                        (*iter->fn)();

The childq in memory points to a node with invalid pointers,
the parentq however executed by the parent is fine.

parentq
0xe4dbf70:      0x0e6020a8 (first)
0xe4dbf74:      0x0e6020a8 (last)

0xe6020a8:      0x00000000 (next)
0xe6020ac:      0x0e468792 (fn)

childq
0xe4dbf68:      0x0e6020b0 (first)
0xe4dbf6c:      0x0e6020b0 (last)

0xe6020b0:      0x89802ed7 (next)
0xe6020b4:      0x134094fc (fn)

The prepareq looks bad too:

prepareq
0xe4da148:      0x0e4dbf78 (first)
0xe4da14c:      0x0e4b2c6d (last)

0xe4dbf78:      0x0e4e76e0 (first->next)
0xe4dbf7c:      0x0e4e76e0 (first->fn)

0xe4e76e0:      0x00000000 (first->next->next)
0xe4e76e4:      0x0e4687b8 (first->next->fn)

0xe4b2c6d:      0x2f686f6d (last->next)
0xe4b2c71:      0x652f6e65 (last->fn)

but the parent process didn't fail.
-- 
-- 
                                Michael van Elst
Internet: [email protected]
                                "A potential Snark may lurk in every tree."