| Jon:
I just did a quick vttest run, and dtterm didn’t crash.
Should we commit the memmove patch then?
(I’ve attached it in git format-patch format.)
—Douglas
|
OpenBSD-5.7.memcpy.patch
Description: Binary data
On Sat, 20 Jun 2015, Douglas Carmichael wrote:Jon:
Thank you for your insights!
With a virgin copy of the libDtTerm code, I was able to trigger the first memcpy() coredump pretty consistently (at line 1972 of TermPrimBuffer.c) with rapid scrolling down an editor session.
But, when I change the memcpy() to a memmove() at line 1972 that particular coredumping event goes away.
Should we push that as a patch, or test it a bit more?
You bet! The way memcpy is used in dtterm is probably mostly wrongsince the opportunity to copy overlapping segments is rather large -something that is 'undefined' for memcpy. In these cases, memmove isalways the right way to go.(What could be a good way to exercise that bit of code?)
In the distant past I used to use a program called vttest, which stillseems to exist in ubuntu's repos at least.http://invisible-island.net/vttest/Though I recall dtterm failed several of the tests at the time (about10 or so years ago), I do not recall it ever crashing dtterm.-jon—Douglas
On Jun 20, 2015, at 7:54 PM, Jon Trulson <j...@radscan.com> wrote:
On Sat, 20 Jun 2015, Douglas Carmichael wrote:
Jon:
I’ve also seen the same crash/coredump case in TermPrimBufferDelete() within TermPrimBuffer.c:
~~~~~~
#0 0x00001f5a61dcb90a in kill () at <stdin>:2
#1 0x00001f5a61e050b9 in abort () at /usr/src/lib/libc/stdlib/abort.c:53
#2 0x00001f5a61dda1d8 in memcpy (dst0=0xfb862, src0=0x6, length=0)
^^^ Well, all of those args to memcpy look pretty wrong, no wonder it
cores. Is this with your patch applied?
Something is going pretty wrong here, though the damage has already
been done by the time this code is reached.
#3 0x00001f59be3404ee in _DtTermPrimBufferDelete (tb=0x1f5a3fba0600, row=Variable
"row" is not available.
)
at TermPrimBuffer.c:1233
This code actually appears to be:
_DtTermDeleteEnhancement() defined in TermBuffer.c, line 688. The
memcpy is being called there (at the end), if that helps to debug.
This also looks like a candidtate to call memmove rather than memcpy,
(as it appears to copy an overlapping buffer) but those args are still
pretty wrong.
[...]
~~~~
Does this give you any clues?
—Douglas
Not to the original cause, no -- though it's pretty clear why memcpy
is coring :) Wonder what is so different from previous version of
OpenBSD... I hadn't heard of any dtterm problems on BSD before.
--
Jon Trulson
"If we can hit that bull's-eye, the rest of the dominoes will fall
like a house of cards... Checkmate."
-- Zapp Brannigan
-- Jon Trulson"If we can hit that bull's-eye, the rest of the dominoes will falllike a house of cards... Checkmate." -- Zapp Brannigan
|
------------------------------------------------------------------------------
_______________________________________________
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
