Attempt to save file via Tramp mode leads to abort

[cbbrowne]

I'm running latest (git pull on 2017-11-23), on Linux, which consistently aborts in the following case...

• Using Tramp mode to access a remote file via ssh (/ssh:cbbrowne@remotehost:~/somefile.sh)

• Make some changes to the file

• Use c-x c-s to save the file

On stderr, I see output of the form...

Backtrace:
remacs[0x505d17]
remacs[0x4ecb37]
remacs[0x505db3]
remacs[0x561d29]
remacs[0x55e888]
remacs[0x55eeb8]
remacs[0x55c67b]
remacs[0x58e015]
remacs[0x55c67b]
remacs[0x55e050]
remacs[0x55c700]
remacs[0x58e015]
remacs[0x55c67b]
remacs[0x55e050]
remacs[0x55c700]
remacs[0x58e015]
remacs[0x55c67b]
remacs[0x55fb4c]
remacs[0x521bea]
remacs[0x522c2f]
remacs[0x55d671]
remacs[0x55c700]
remacs[0x58e015]
remacs[0x55c67b]
remacs[0x58e015]
remacs[0x55c67b]
remacs[0x58e015]
remacs[0x55c67b]
remacs[0x58e015]
remacs[0x55c67b]
remacs[0x55919d]
remacs[0x55c700]
remacs[0x559a49]
remacs[0x55c700]
remacs[0x58e015]
remacs[0x55c67b]
remacs[0x55c7ba]
remacs[0x4faffc]
remacs[0x55b93e]
remacs[0x4ecef4]
remacs[0x55b8ad]
...

[1] + 1780 abort remacs

The entire remacs session terminates at that point.

This has been repeatable for a couple of weeks. This is obviously a few layers deep into ssh + tramp, and I'm not sure at all what to point at as cause or effect.

[cbbrowne]

I ran this again inside a gdb session, and it's somewhat more informative...

#0 0x00007ffff1ea2f9f in raise () at /lib/x86_64-linux-gnu/libpthread.so.0
#1 0x00000000004ecb04 in terminate_due_to_signal (sig=sig@entry=6, backtrace_limit=backtrace_limit@entry=40) at emacs.c:389
#2 0x0000000000505db3 in emacs_abort () at sysdep.c:2326
#3 0x0000000000561d29 in Fbase64_encode_region (beg=, end=, no_line_break=) at fns.c:2169
#4 0x000000000055e888 in eval_sub (form=) at eval.c:2237
#5 0x000000000055eeb8 in Fprogn (body=) at eval.c:455
#6 0x000000000055eeb8 in funcall_lambda (fun=56207363, nargs=nargs@entry=2, arg_vector=arg_vector@entry=0x7fffffffa2f8) at eval.c:3042
#7 0x000000000055c67b in Ffuncall (nargs=3, args=args@entry=0x7fffffffa2f0) at eval.c:2780
#8 0x000000000058e015 in exec_byte_code (bytestr=, vector=53448901, maxdepth=, args_template=, nargs=nargs@entry=28, args=, args@entry=0x1c)
at bytecode.c:629
#9 0x000000000055ec60 in funcall_lambda (fun=140737488331640, nargs=28, nargs@entry=7, arg_vector=0x1c, arg_vector@entry=0x7fffffffb338) at eval.c:2967
#10 0x000000000055c67b in Ffuncall (nargs=nargs@entry=8, args=0x7fffffffb330) at eval.c:2780
#11 0x000000000055e050 in Fapply (nargs=2, args=0x7fffffffb460) at eval.c:2386
#12 0x000000000055c700 in Ffuncall (nargs=, args=args@entry=0x7fffffffb458) at eval.c:2766
#13 0x000000000058e015 in exec_byte_code (bytestr=, vector=53450677, maxdepth=, args_template=, nargs=nargs@entry=25, args=, args@entry=0x19)
at bytecode.c:629
#14 0x000000000055ec60 in funcall_lambda (fun=140737488336008, nargs=25, nargs@entry=8, arg_vector=0x19, arg_vector@entry=0x7fffffffb668) at eval.c:2967
#15 0x000000000055c67b in Ffuncall (nargs=nargs@entry=9, args=0x7fffffffb660) at eval.c:2780
#16 0x000000000055e050 in Fapply (nargs=3, args=0x7fffffffb808) at eval.c:2386
#17 0x000000000055c700 in Ffuncall (nargs=, args=args@entry=0x7fffffffb800) at eval.c:2766
#18 0x000000000058e015 in exec_byte_code (bytestr=, vector=58659477, maxdepth=, args_template=, nargs=nargs@entry=19, args=, args@entry=0x13)
at bytecode.c:629
#19 0x000000000055ec60 in funcall_lambda (fun=140737488337016, nargs=19, nargs@entry=8, arg_vector=0x13, arg_vector@entry=0x7fffffffc008) at eval.c:2967
#20 0x000000000055c67b in Ffuncall (nargs=nargs@entry=9, args=args@entry=0x7fffffffc000) at eval.c:2780
#21 0x000000000055fb4c in call8 (fn=fn@entry=43082752, arg1=arg1@entry=56400, arg2=, arg3=, arg4=arg4@entry=63913924, arg5=arg5@entry=0, arg6=49152, arg7=49283140, arg8=0)
at eval.c:2680
#22 0x0000000000521bea in write_region (start=, end=, filename=63913924, append=0, visit=49152, lockname=49283140, mustbenew=0, desc=-1) at fileio.c:4732
#23 0x0000000000522c2f in Fwrite_region (start=, end=, filename=, append=, visit=, lockname=, mustbenew=0)
at fileio.c:4666
#24 0x000000000055d671 in funcall_subr (subr=0xa0bda0 <Swrite_region>, numargs=numargs@entry=6, args=args@entry=0x7fffffffc658) at eval.c:2866
#25 0x000000000055c700 in Ffuncall (nargs=, args=args@entry=0x7fffffffc650) at eval.c:2766
#26 0x000000000058e015 in exec_byte_code (bytestr=, vector=10915965, maxdepth=, args_template=, nargs=nargs@entry=16, args=, args@entry=0x10)
at bytecode.c:629
#27 0x000000000055ec60 in funcall_lambda (fun=140737488340632, nargs=16, nargs@entry=0, arg_vector=0x10, arg_vector@entry=0x7fffffffc9a0) at eval.c:2967
#28 0x000000000055c67b in Ffuncall (nargs=1, args=args@entry=0x7fffffffc998) at eval.c:2780
#29 0x000000000058e015 in exec_byte_code (bytestr=, vector=10915845, maxdepth=, args_template=, nargs=nargs@entry=15, args=, args@entry=0xf)
at bytecode.c:629
#30 0x000000000055ec60 in funcall_lambda (fun=140737488341424, nargs=15, nargs@entry=0, arg_vector=0xf, arg_vector@entry=0x7fffffffcbb0) at eval.c:2967
#31 0x000000000055c67b in Ffuncall (nargs=1, args=args@entry=0x7fffffffcba8) at eval.c:2780
#32 0x000000000058e015 in exec_byte_code (bytestr=, vector=10915021, maxdepth=, args_template=, nargs=nargs@entry=12, args=, args@entry=0xc)
at bytecode.c:629
#33 0x000000000055ec60 in funcall_lambda (fun=140737488341968, nargs=12, nargs@entry=1, arg_vector=0xc, arg_vector@entry=0x7fffffffcf10) at eval.c:2967
#34 0x000000000055c67b in Ffuncall (nargs=2, args=args@entry=0x7fffffffcf08) at eval.c:2780
#35 0x000000000058e015 in exec_byte_code (bytestr=, vector=10914269, maxdepth=, args_template=, nargs=nargs@entry=10, args=, args@entry=0xa)
at bytecode.c:629
#36 0x000000000055ec60 in funcall_lambda (fun=140737488342816, nargs=10, nargs@entry=0, arg_vector=0xa, arg_vector@entry=0x7fffffffd140) at eval.c:2967
#37 0x000000000055c67b in Ffuncall (nargs=1, args=args@entry=0x7fffffffd138) at eval.c:2780
#38 0x000000000058e015 in exec_byte_code (bytestr=, vector=10908357, maxdepth=, args_template=, nargs=nargs@entry=9, args=, args@entry=0x9)
at bytecode.c:629
#39 0x000000000055ec60 in funcall_lambda (fun=140737488343384, nargs=9, nargs@entry=2, arg_vector=0x9, arg_vector@entry=0x7fffffffd3e0) at eval.c:2967
#40 0x000000000055c67b in Ffuncall (nargs=nargs@entry=3, args=args@entry=0x7fffffffd3d8) at eval.c:2780
#41 0x000000000055919d in Ffuncall_interactively (nargs=3, args=0x7fffffffd3d8) at callint.c:252
#42 0x000000000055c700 in Ffuncall (nargs=nargs@entry=4, args=0x7fffffffd3d0) at eval.c:2766
#43 0x000000000055e050 in Fapply (nargs=nargs@entry=3, args=args@entry=0x7fffffffd510) at eval.c:2386
#44 0x000000000055a5d7 in Fcall_interactively (function=4811504, record_flag=0, keys=) at callint.c:389
#45 0x000000000055c700 in Ffuncall (nargs=, args=args@entry=0x7fffffffd5e8) at eval.c:2766
#46 0x000000000058e015 in exec_byte_code (bytestr=, vector=11331485, maxdepth=, args_template=, nargs=nargs@entry=5, args=, args@entry=0x5)
at bytecode.c:629
#47 0x000000000055ec60 in funcall_lambda (fun=140737488344608, nargs=5, nargs@entry=1, arg_vector=0x5, arg_vector@entry=0x7fffffffd888) at eval.c:2967
#48 0x000000000055c67b in Ffuncall (nargs=nargs@entry=2, args=args@entry=0x7fffffffd880) at eval.c:2780
#49 0x000000000055c7ba in call1 (fn=fn@entry=16080, arg1=) at eval.c:2617
#50 0x00000000004faffc in command_loop_1 () at keyboard.c:1481
#51 0x000000000055b93e in internal_condition_case (bfun=bfun@entry=0x4fac00 <command_loop_1>, handlers=handlers@entry=21024, hfun=hfun@entry=0x4f1e20 <cmd_error>) at eval.c:1332
#52 0x00000000004ecef4 in command_loop_2 (ignore=ignore@entry=0) at keyboard.c:1109
#53 0x000000000055b8ad in internal_catch (tag=tag@entry=50784, func=func@entry=0x4eced0 <command_loop_2>, arg=arg@entry=0) at eval.c:1097
#54 0x00000000004ece8b in command_loop () at keyboard.c:1088
#55 0x00000000004f1a33 in recursive_edit_1 () at keyboard.c:694
#56 0x00000000004f1d4e in Frecursive_edit () at keyboard.c:765
#57 0x000000000041712d in main (argc=, argv=0x7fffffffdc78) at emacs.c:1667

[DavidDeSimone]

Hello @cbbrowne , is this happening for any arbitrary file? That stack trace is leading me to believe that this is tied to the data that is being base64 encoded in the region. The code in question:

  encoded_length = base64_encode_1 ((char *) BYTE_POS_ADDR (ibeg),
				    encoded, length, NILP (no_line_break),
				    !NILP (BVAR (current_buffer, enable_multibyte_characters)));
  if (encoded_length > allength)
    emacs_abort ();

[cbbrowne]

I did test with multiple files; all were pretty plain text. In the case for which I dropped in the backtrace, the only file edited in the session was a shell script. (An "init" script to start up PostgreSQL in user space, though that's probably not highly relevant!)

There should not have been any base64 portions of the buffer; it was plain old shell script, no UTF-8 or such to complicate life.

That said, this was in Tramp mode, using ssh to transmit data. I would not be at all surprised if Tramp mode re-encodes data into base64 for transmission.

[shaleh]

This reproduces easily. Fire up remacs, make a region out of some text and do m-x base64-encode-region. Bam!! Dead.

[shaleh]

To be more exact, it appears to fail when the entire buffer is encoded. So open a file and try to encode the whole thing.

[shaleh]

So it turns out we were not passing the option we needed to the base64 crate. This leads to us using more memory than expected and triggering the check which called emacs_abort.

The PR sets the proper value.

[cbbrowne]

With that change, I am no longer experiencing the aborts, so that sure does look like an improvement.

[shaleh]

👍