"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
Can you find out what the coding-system is (see stack frame #8)?
I don't know how to get it offhand, but if you source .gdbinit in the
src/ subdirectory and use the pobj function, you may be able to figure
out what it is.
Hmm, here's a couple of numbers, but I'm pretty sure, you would like
to see more ...
(gdb) pobj coding_system
$22 = (struct lstream *) 0x8a65b80
$23 = {header = {lheader = {type = 15, mark = 0, c_readonly = 0,
lisp_readonly = 0}, next = 0x92de880, uid = 25466, free = 0},
imp = 0x81ea040, buffering = LSTREAM_BLOCK_BUFFERED, buffering_size = 512,
in_buffer = 0x0, in_buffer_size = 512, in_buffer_current = 0,
in_buffer_ind = 0, out_buffer = 0x0, out_buffer_size = 0,
out_buffer_ind = 0, unget_buffer = 0x0, unget_buffer_size = 0,
unget_buffer_ind = 0, byte_count = 0, flags = 2, data = {{...}}}
I can't get through to the data member, at least I don't know a nifty
function which would tell me :-)
Why Gnus is using a CCL coding system is something I'd really
like
to know.
Simon might know something about. He was pretty actively committing
during the time this crash first occurred.
Are you using Mule-UCS?
Seems to: 'mule-ucs-autoloads' is listed in features.
norbert.