lynx-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

lynx-dev Unclean exits - with patch, request for comments


From: Klaus Weide
Subject: lynx-dev Unclean exits - with patch, request for comments
Date: Tue, 1 Dec 1998 15:40:50 -0600 (CST)

When Lynx is terminating abnormally, with ^C or similar, it may
still try to clean up all allocated memory (as well as remove
temp files and other normal exit processing).  But ^C may happen
at times where some internal structures are in a temporary state
that doesn't allow clean termination.  A memory access violation
or similar error can then occur, generating another signal which
prevents the attempted cleanup from finishing.  One then gets

   Exiting via interrupt: 2

   Please notify your system administrator to confirm a bug, and
   ... [ some more lines ] ...

   Lynx now exiting with signal: 11

or similar, instead of just the first line.

Well, so far the theory.  I seemed to have found a test case where
I could consistently produce this kind of unclean exit by pressing
^C at the right time (during loading of a file).  That's why I started
looking at core dumps, tracing things, and came up with the patches
below - they seemed to solve the problem.  Unfortunately(?) now, even
when I back out the patches, the double-interrupt doesn't occur any
more in the test case - the problem seems to have solved itself!
(Or I made some other changes that should be unrelated, but they
prevent the problem from being triggered.)

So my question is, how often does ^C produce an unclean exit
(with message as above) for others?  If this happens for you,
could you try these patches and see whether they make a difference?

(Pressing ^C while Lynx is idle waiting for a key doesn't count; it
should happen while it is trying to load a document.)

  Klaus


* Prevent havoc (acces to already freed memory etc.) caused by
  multiple recursive invocations of HTAnchor_delete on the same
  HTParentAnchor.  This does not seem to actually happen normally
  during a session, but can occur when the HTAnchor structures are
  cleaned up while handling a terminating signal or outofmem condition.
* Reset the HTAnchor "underway" flag during final cleanup, so
  structures are not prevented from being freed.  This also should
  only make a difference when handling a terminating signal or outofmem
  condition.


Patch should work for rel and dev code.

*** lynx2-8-1.orig/WWW/Library/Implementation/HTAnchor.c        Sun Sep 13 
09:35:55 1998
--- lynx2-8-1/WWW/Library/Implementation/HTAnchor.c     Mon Nov 30 21:12:02 1998
***************
*** 275,280 ****
--- 275,281 ----
            adult_table[i_counter] = HTAp_freeme->next;
            if (HTAp_freeme->object) {
                parent = (HTParentAnchor *)HTAp_freeme->object;
+               parent->underway = FALSE;
                HTAnchor_delete(parent);
            }
            FREE(HTAp_freeme);
***************
*** 420,425 ****
--- 421,434 ----
        HTParentAnchor *parent = me->mainLink.dest->parent;
  
        /*
+        *  Set the mainLink pointer to zero NOW.  If we don't,
+        *  and we get somehow called recursively again for this
+        *  same old me during the HTAnchor_delete below, weird
+        *  things can occasionally happen. - kw
+        */
+        me->mainLink.dest = NULL;
+ 
+       /*
         *  Remove me from the parent's sources so that the
         *  parent knows one less anchor is it's dest.
         */
***************
*** 451,457 ****
         *  Leave the HTAtom pointed to by type up to other code to
         *  handle (reusable, near static).
         */
-       me->mainLink.dest = NULL;
        me->mainLink.type = NULL;
      }
  
--- 460,465 ----
***************
*** 544,549 ****
--- 552,563 ----
      }
  
      /*
+      *  Mark ourselves busy, so that recursive calls of this function
+      *  on this HTParentAnchor will not free it from under our feet. - kw
+      */
+     me->underway = TRUE;
+ 
+     /*
       *        Recursively try to delete destination anchors of this parent.
       *        In any event, this will tell all destination anchors that we
       *        no longer consider them a destination.
***************
*** 569,574 ****
--- 583,589 ----
                }
            }
        }
+       me->underway = FALSE;
  
        /*
         *  Can't delete parent, still have sources.
***************
*** 592,597 ****
--- 607,613 ----
            }
        }
      }
+     me->underway = FALSE;
  
      /*
       *        Delete our empty list of children.
*** lynx2-8-1.orig/src/GridText.c       Wed Oct 14 07:23:56 1998
--- lynx2-8-1/src/GridText.c    Mon Nov 30 21:14:48 1998
***************
*** 584,590 ****
            }
        }
        if (l == self->last_line) {     /* empty */
!           l = NULL;
            break;
        }
      };
--- 584,590 ----
            }
        }
        if (l == self->last_line) {     /* empty */
!           l = self->last_line = NULL;
            break;
        }
      };
***************
*** 8029,8034 ****
--- 8029,8036 ----
       */
      while (loaded_texts && !HTList_isEmpty(loaded_texts)) {
        if ((cur = (HText *)HTList_removeLastObject(loaded_texts)) != NULL) {
+           if (cur->node_anchor && cur->node_anchor->underway)
+               cur->node_anchor->underway = FALSE;
            HText_free(cur);
        }
      }

reply via email to

[Prev in Thread] Current Thread [Next in Thread]