Re: segfault in read_process_output() during vc-diff

[Tim Van Holder]

On 11/7/06, Kim F. Storm <address@hidden> wrote:
> > #1  0x081864d4 in read_process_output (proc=143372852, channel=<value optimized 
> out>) at /home/tim/gnu/src/emacs/src/process.c:5144
> >         odeactivate = 137457249
> >         text = 142872947
> >         outer_running_asynch_code = 0
> >         waiting = -1
> >         nbytes = <value optimized out>
> >         outstream = 137502441
> >         old = (struct buffer *) 0x88fb2b8
> >         p = (struct Lisp_Process *) 0x88bb230
> >         opoint = <value optimized out>
> >         coding = (struct coding_system *) 0x88fb4c0
> >         carryover = -1316
>
> This looks very suspicious.
>
> Can you print the "coding" variable and the "p" variable:
>
> up 1
> p *coding
> p *p

(gdb) p *coding
$1 = {
 type = coding_type_iso2022,
 eol_type = 0,
 common_flags = 7,
 flags = 6144,
 mode = 0,
 composing = 0,
 composition_rule_follows = 0,
 cmp_data = 0x0,
 cmp_data_start = 0,
 cmp_data_index = 0,
 spec = {
   iso2022 = {
     current_invocation = {0, 1},
     current_designation = {0, 129, -1, -1},
     initial_designation = {0, 129, -1, -1},
     last_invalid_designation_register = -1,
     requested_designation = "\000", '\004' <repeats 128 times>,
"\001", '\004' <repeats 125 times>,
     charset_revision_number = '\377' <repeats 255 times>,
     single_shifting = 0,
     bol = 1
   },
   ccl = {
     decoder = {
       idx = 0,
       size = 1,
       prog = 0x0,
       ic = 129,
       eof_ic = -1,
       reg = {-1, 0, 129, -1, -1, -1, 67372032, 67372036},
       private_state = 67372036,
       last_block = 67372036,
       status = 67372036,
       buf_magnification = 67372036,
       stack_idx = 67372036,
       eol_type = 67372036,
       multibyte = 67372036,
       cr_consumed = 67372036,
       suppress_error = 67372036,
       eight_bit_control = 67372036
     },
     encoder = {
       idx = 67372036,
       size = 67372036,
       prog = 0x4040404,
       ic = 67372036,
       eof_ic = 67372036,
       reg = {67372036, 67372036, 67372036, 67372036, 67372036,
67372036, 67372036, 67372036},
       private_state = 67372036,
       last_block = 67372036,
       status = 67372036,
       buf_magnification = 67372036,
       stack_idx = 67372036,
       eol_type = 67372036,
       multibyte = 67372036,
       cr_consumed = 67371268,
       suppress_error = 67372036,
       eight_bit_control = 67372036
     },
     valid_codes = '\004' <repeats 115 times>, '\377' <repeats 141 times>,
     cr_carryover = -1,
     eight_bit_carryover = "\377\377\377\377"
   }
 },
 category_idx = 4,
 src_multibyte = 0,
 dst_multibyte = 1,
 heading_ascii = 2374,
 produced = 2374,
 produced_char = 2374,
 consumed = 2374,
 consumed_char = 2374,
 errors = 0,
 result = 1,
 suppress_error = 0,
 symbol = 137802753,
 post_read_conversion = 137457249,
 pre_write_conversion = 137457249,
 translation_table_for_decode = 137457249,
 translation_table_for_encode = 139621236
}

Suspicious indeed - I can't think of any reason why
coding_type_iso2022 would be used (locale is en_US.UTF8, and language
environment is English).

(gdb) p *p
$2 = {
 size = 1073742364,
 v_next = 0x8828c08,
 infd = 40,
 outfd = 104,
 tty_name = 137457249,
 name = 141293123,
 command = 143161269,
 filter = 143185969,
 sentinel = 143488149,
 log = 137457249,
 buffer = 142774828,
 childp = 137457297,
 plist = 137457249,
 mark = 140625498,
 kill_without_query = 137457249,
 status = 137603945,
 pty_flag = 137457249,
 tick = 8,
 update_tick = 8,
 decode_coding_system = 137802753,
 decoding_buf = 143668003,
 decoding_carryover = 0,
 encode_coding_system = 137802705,
 encoding_buf = 143667987,
 encoding_carryover = 0,
 inherit_coding_system_flag = 137457249,
 filter_multibyte = 137457297,
 adaptive_read_buffering = 137457297,
 read_output_delay = 0,
 read_output_skip = 137457249,
 pid = 10948,
 raw_status_new = -1,
 raw_status = 256
}