[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: lynx-dev dev11 core dump in LYEdit.c under DJGPP
From: |
dickey |
Subject: |
Re: lynx-dev dev11 core dump in LYEdit.c under DJGPP |
Date: |
Fri, 25 Dec 1998 18:02:31 -0500 (EST) |
>
> >>
> >> The new problem appears a couple of dev versions ago:
> >> when I look localfile with DJGPP port and press 'e' to edit the file
> >> I got a crash immediately.
> >>
> >> gdb shows a crash from extra free() in
> >> edit_current_file() at LYEdit.c:129 (quoted below):
>
> > thanks (will check/fix)
>
> >> #ifdef __DJGPP__
> >> sprintf(command, "%s %s", editor, HTDOS_name(filename));
> >> #else
> >> sprintf(command, "%s \"%s\"", editor, HTSYS_name(filename));
> >> #endif /* __DJGPP__ */
> >> #endif /* VMS */
> >> CTRACE(tfp, "LYEdit: %s\n", command);
> >> CTRACE_SLEEP(MessageSecs);
> >> #ifndef __EMX__
> >> ----> FREE(filename);
> >> #endif
> >>
> >> /*
> >> * Invoke the editor. - FM
> >>
> >>
> >> I change the condition to
> >> #if !defined(__EMX__) && !defined(__DJGPP__)
> >> and it works OK but I do not know the origin of the problem
> >> so expect problems elsewhere.
>
> > well, it doesn't seem to be directly related to the HTSprintf changes.
> > Perhaps I moved an ifdef.
>
> No. I checked against 2.8.1rel:
> LYEdit.c, HTSYS_name(), HTDOS_name() was not changed but the problem come.
> Probably certain memory problems was hidden until you change something.
with the last few patches, I've replaced some fixed buffers with ones
that are allocated. I've _looked_ (but can miss) places where the
calling code extends the buffer by simplying concatenating new characters
onto it. Perhaps that is the problem.
> In fact, HTSYS_name() equivalent to HTDOS_name() for __EMX__ and DOSPATH,
> but HTDOS_name() do the odd thing - it returns a pointer to initial argument
> which is modified. This is not intended for HTVMS_name() so we got
> HTDOS_name() argument converted several times in edit_current_file()
> and possibly other places. Should we fix HTDOS_name ?
probably a good thing to fix. I was looking at this (or something
similar) the other night, and it was returning a pointer to a static (1024)
buffer. I wanted to replace the buffer with an allocated one, but the
calling code was a little messy - some places it seems to assume that
the buffer is longer than the string. So I put it off for another day.
> Trace have the folowing entries:
>
> HTParse: result:/c:/lynx/dist28/lynx2-8-/src/chrtrans/cp1250_u.h
> HTDOS_name changed `c:/lynx/dist28/lynx2-8-/src/chrtrans/cp1250_u.h' to
> `c:\lynx\dist28\lynx2-8-\src\chrtrans\cp1250_u.h'
> HTDOS_name changed `c:\lynx\dist28\lynx2-8-\src\chrtrans\cp1250_u.h' to
> `c:\lynx\dist28\lynx2-8-\src\chrtrans\cp1250_u.h'
>
>
> > --
> > Thomas E. Dickey
>
>
--
Thomas E. Dickey
address@hidden
http://www.clark.net/pub/dickey