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)
at /usr/src/lib/libc/string/memcpy.c:65
#3 0x00001f59be3404ee in _DtTermPrimBufferDelete (tb=0x1f5a3fba0600,
row=Variable "row" is not available.
)
at TermPrimBuffer.c:1233
#4 0x00001f59be356160 in _DtTermFuncDeleteChar (w=0x1f59f201ec00,
count=Variable "count" is not available.
)
at TermFunction.c:471
#5 0x00001f59be344f05 in _DtTermPrimParse (w=0x1f59f201ec00,
parseChar=0x7f7ffffc1cfb "P\r\017Modified\033[13;30H\033[\020",
parseCharLen=Variable "parseCharLen" is not available.
)
at TermPrimParser.c:206
#6 0x00001f59be345a8e in _DtTermPrimParseInput (w=0x1f59f201ec00,
buffer=0x7f7ffffc1cf0 "\b#define\033[8P\r\017Modified\033[13;30H\033[\020",
len=13,
dangleBuffer=0x7f7ffffc1ce0, dangleBufferLen=0x7f7ffffc1cec) at
TermPrimRender.c:1465
#7 0x00001f59be33a12e in readPty (client_data=0x1f59f201ec00,
source=0x1f5a8499dee8, id=Variable "id" is not available.
) at TermPrim.c:2948
#8 0x00001f5a744a505c in XtAppProcessEvent () from /usr/X11R6/lib/libXt.so.11.0
#9 0x00001f5a744972fd in XtAppMainLoop () from /usr/X11R6/lib/libXt.so.11.0
#10 0x00001f579680953f in main (argc=1, argv=0x7f7ffffc29c8) at
DtTermMain.c:1433
~~~~
Does this give you any clues?
—Douglas
> On Jun 19, 2015, at 1:29 PM, Jon Trulson <j...@radscan.com> wrote:
>
> On Fri, 19 Jun 2015, Douglas Carmichael wrote:
>
>> To whom it may concern:
>>
>> Attached is a small patch to not define USE_MEMCPY in libDtTerm on OpenBSD
>> 5.7.
>>
>> This is a workaround for the dtterm coredumps mentioned in ticket #50.
>>
>> —Douglas
>>
>>
>
> Hi, a couple of things:
>
> I'm wondering if instead of memcpy, memmove should be used in these
> places. Have you tried replacing these memcpy's with memmove instead?
>
> But as I look closer -
>
> Another thing I notice, is that in the memcpy case, the number of
> bytes to copy is the (length * sizeof(TermLine)), whereas in the
> non-memcpy cases it is simply the length. This seems not quite right,
> and unless I'm missing something obvious, these cases do not copy the
> same number of bytes, which should be a red flag right there.
>
> It is not clear off-hand which is correct - your change just seems to
> hide the problem. I suspect that perhaps the '* sizeof(TermLine)'
> might not be correct in the memcpy case, since TermLine is a pointer
> and sizeof(TermLine) will be either 4 bytes in the 32b arch case or 8
> bytes in the 64b arch case. Investigation is needed.
>
> I guess what I'm saying is there is something more going on here, and
> I'd rather the actual problem be understood and solved rather than
> bandaged over.
>
> Anybody have thoughts on this?
>
> Also: For some reason, your OSX mailer marks patch file attachments as
> binary/octet-stream attachments, which means that it is not possible to view
> the patch in a mail viewer - it must be saved to a file first and
> then viewed with a text editor, which is a PITA. Could you fix that?
>
> --
> 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
------------------------------------------------------------------------------
_______________________________________________
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
