[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference vaxuum::document_ft

Title:	DOCUMENT T1.0
Notice:	New notesfile (DOCUMENT.NOTE) now available (see note 897)
Moderator:	CLOSET::ADLER

Created:	Mon Feb 09 1987
Last Modified:	Thu Oct 31 1991
Last Successful Update:	Fri Jun 06 1997
Number of topics:	897
Total number of notes:	4397

109.0. "Symbols too long bug" by DECWET::CUSTER () Fri Mar 13 1987 18:54

How disconcerting it is to begin processing a large manual and near the end
of the 2nd pass (15 minutes later), receive a message like this: 
    	
    	"Improperly handled condition, image exit forced."
    
and a stack and register dump.   :-( 
    
The immediately preceding error message was this: 
    
    %TAG-F-STRFREE2T, at tag <COMPARE> on line 923 in file
       3222CH4.GNC
       Internal error.  Attempt to free the same string twice
        
I looked at line 923 in the specified chapter and here was the offending
text: 
    
    "See <REFERENCE>(resolving_multiply_defined_symbols) for more information"
    
I guess DOCUMENT *really* doesn't like it when your symbols are more than
31 characters!  I mention the error here because the manual says:
    
    	"GUTENTAG'S memory allocation algorithm has failed.  This error
    should not occur....Please report this as a bug.
    
So there you go!
 
    
    	-hkc

T.R	Title	User	Personal Name	Date	Lines
109.1	We'll fix the bug in pass 2 and check length.	CLOSET::KOHLBRENNER		`Mon Mar 16 1987 08:37`	15
	That sure is disconcerting. The <reference> tag does most of its work in pass 2, since it can't count on having the symbol definition in pass 1. However, we could check the length of the symbol and tell you it's too long in pass 1. THe Fatal error is indeed a bug, for which we are grateful to you (as a field test user) for finding and reporting... I presume the problem went away when you shortened the name in the <reference> tag? bill
109.2	You do check length, but message is misleading.	DECWET::CUSTER		`Mon Mar 16 1987 12:16`	12
	Pardon....I forgot to mention that the program did identify the symbol as too long in pass 1. However, because of the message I received ("The truncated name is ...."), I assumed the tag translator was actually truncating the symbol internally, so expected pass 2 to complete normally. Yes, indeed, making the symbol shorter did fix the problem. (Now I'm just getting infinite TEX loops....sigh.) Thanks. -hkc
109.3	loops are a different bug?	CLOSET::ANKLAM		`Mon Mar 16 1987 12:21`	2
	Infinite TeX loops? Please tell me why...
109.4	Works sometimes	BUNSUP::LITTLE	Todd Little	`Tue Mar 17 1987 16:52`	6
	There may be more to the problem than just a symbol name too long, because I've sucessfully processed documents with invalid symbol names. I know pass 1 gave the error message about symbol too long, and I think pass 2 just gave a symbol not defined error message. -tl
109.5	Weird!	DECWET::CUSTER		`Tue Mar 17 1987 17:01`	13
	Re .3 See Note 118. Re .4 You may be right that overlong symbol names are not the only problem. However, the line number that the last error message appeared on was the one containing a reference to a 34-character symbol name. And, strangely enough, the job did not blow up when I corrected that symbol name. If you're right, then something weird is happening! -hkc
109.6	Confusion	VAXUUM::KOHLBRENNER		`Wed Mar 18 1987 08:34`	9
	Helen's problem is a <reference>(1234567890123456789012345678901234) tag. The tag translator makes a copy of the first 31 characters, so that it can report both the 34-char and the 31-char names in the error message. Then it gets its pointers to strings mixed up and ends up trying to do away with the 34 character string TWICE. The code checks itself for that kind of confusion and stops with the STRFREE2T error message. Fixed in the FT update.