Date: Sat, 09 Dec 2006 18:21:12 -0600 From: User1001 <supraexpress@globaleyes.net> To: freebsd-openoffice@freebsd.org Subject: Re: Digital Signatures in Ooo-2.0.3 Message-ID: <pan.2006.12.10.00.21.04.623384@globaleyes.net> References: <pan.2006.11.16.07.04.32.720574@globaleyes.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 16 Nov 2006 01:04:34 -0600, User1001 wrote:
> Every time that I attempt to try the digital signature process, Ooo-2.0.3
> either crashes or says something about a profile that it can't find,
> though I have eliminated extraneous .mozilla and/or .thunderbird user
> directories (from older installs). Is "digital signatures" considered an
> unstable feature?
I have confirmed the "mozilla profile" problem as coming from old
".mozilla" directory entries that were created with an older Mozilla
browser, which pointed to non-existant subdirectories. Removing or
renaming all such entries forced/allowed Ooo to search for "other
profiles", first starting in ".mozilla", then going on to ".thunderbird".
KTRACE now shows Ooo reading <thunderbird><user> cert8.db and key3.db
files, but still crashes.
Interestingly enough, the trace dump shows Ooo reading only part of both
cert8.db and key3.db, and never reading in any actual entries - only "null
space". The last READ command specifies 0x4000 bytes to read, but the
trace shows only 0x0ff0 bytes read (?). Immediately after reading bytes
from key3.db, the trace shows the crash:
47694 soffice.bin CALL read(0x2e,0x8569600,0x104)
47694 soffice.bin GIO fd 46 read 260 bytes
0x0000 0006 1561 0000 0002 0000 04d2 0000 4000 0000 000e |...a..........@.....|
0x0014 0000 0100 0000 0100 0000 0008 0000 0001 0000 0002 |....................|
0x0028 0000 0001 0000 0003 0000 0001 0001 0000 0000 0004 |....................|
0x003c 0000 0001 956e 7de3 0000 0000 0000 0002 0000 0002 |.....n}.............|
0x0050 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 |....................|
0x0064 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 |....................|
0x0078 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 |....................|
0x008c 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 |....................|
0x00a0 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 |....................|
0x00b4 0000 0000 0000 0000 0000 0000 0000 0000 0801 0000 |....................|
0x00c8 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 |....................|
0x00dc 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 |....................|
0x00f0 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 |....................|
.
.
.
47694 soffice.bin CALL read(0x2e,0x8598000,0x4000)
47694 soffice.bin GIO fd 46 read 4096 bytes
0x0000 0600 f93f f83f ed3f dd3f cf3f 9f3f 8d3f 9f3f ffff |...?.?.?.?.?.?.?.?..|
.
.
.
0x0fdc ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff |....................|
0x0ff0 ffff ffff ffff ffff ffff ffff ffffffff |................|
47694 soffice.bin RET read 16384/0x4000
47694 soffice.bin PSIG SIGSEGV caught handler=0x28fdc5af mask=0xfffefaff
code=0xc
According to ghex2, "real data" doesn't occur until about BCA0 bytes into
key3.db. Both cert8.db and key3.db have a filesize of 64KB.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?pan.2006.12.10.00.21.04.623384>