[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: crash on resize in demos/command.c
From: |
Lucas Gonze |
Subject: |
Re: crash on resize in demos/command.c |
Date: |
Sat, 21 Dec 2002 09:32:37 -0500 (EST) |
The crash is in the malloc call in the ungetch call in resizeterm, so the
cause is almost certain to be two conflicting calls to malloc. I have not
been able to find a cause of the conflicting calls in the CDK source, so I
don't have a patch that would solve the problem generically.
A workaround is to not do the ungetch in resizeterm:
...
if (is_term_resized(ToLines, ToCols)) {
#if USE_SIGWINCH
/* LG edit */
#if 0
ungetch(KEY_RESIZE); /* so application can know this */
#endif
clearok(curscr, TRUE); /* screen contents are unknown */
#endif
result = resize_term(ToLines, ToCols);
}
...
In my application code, I can find out whether a KEY_RESIZE would have
been received by checking to see whether the results of getmaxyx() have
changed, so the loss of the KEY_RESIZE event doesn't matter.
A generic way to package this would be to add a publically settable flag,
then check the flag before invoking ungetch. This might be as simple as:
in CDK:
putenv("NCURSES_NO_GETCH=true");
in resizeterm:
...
if (is_term_resized(ToLines, ToCols)) {
#if USE_SIGWINCH
if( !getenv("NCURSES_NO_GETCH") )
ungetch(KEY_RESIZE); /* so application can know this */
clearok(curscr, TRUE); /* screen contents are unknown */
#endif
result = resize_term(ToLines, ToCols);
}
...
Though this is a workaround instead of a fix, it would probably be called
for anyway, since there are probably badly behaved user apps that call
malloc in a signal handler.
Loss of the KEY_RESIZE event is unlikely to break any existing CDK
applications, since existing CDK apps don't survive a resize and hence
don't process KEY_RESIZE events.
- Lucas