* Marc Lehmann:
> Unfortunately, the database was recreated in the meantime, "fixing" the
> problem (the db utilities cna read the newly created environment), so I
> have to work from past knowledge on this problem.
Since DB_ENV->set_thread_count is just a minor optimization, maybe you
can get ri
* Marc Lehmann:
> after upgrading to 4.6, this apparently changed. wether caused by an
> upgraded 4.5 database or simply because the 4.6 utilities don't work
> anymore (or don't happen to work by chance) with environments configured
> with set_thread_count (the documentation for that method says a
* Marc Lehmann:
>> We need a sample to debug this further.
>
> Ok, I will try to come up with a small archive of an environment (I can
> probably choose between x86 and amd64 - any preference?).
I don't mind. amd64 is slightly easier for me, but not much.
>> > also, the database files are not p
* Marc Lehmann:
> in short, 4.6 seems to be pretty hosed, the same app has worked fine with
> db4.5 and db4.4 (the app still works with 4.6, but the utilities don't).
We need a sample to debug this further.
> also, the database files are not portable among architectures (a database
> file create
On Fri, Dec 28, 2007 at 10:50:25PM +0100, Marc Lehmann wrote:
>
> the db4.6-utils seem pretty hosed:
>
> db4.6_dump segfaults:
>
>db: Berkeley DB (Btree, version 9, native byte-order)
># db4.6_dump db
>Segmentation fault
>(backtrace shows some crash in __memp_resize b
Package: db4.6-util
Version: 4.6.21-4
Severity: important
the db4.6-utils seem pretty hosed:
db4.6_dump segfaults:
db: Berkeley DB (Btree, version 9, native byte-order)
# db4.6_dump db
Segmentation fault
(backtrace shows some crash in __memp_resize but is otherwise usele
6 matches
Mail list logo
