kakoune: Exception "Format string parameter index too big" on startup, Cygwin (release builds only)

Hi,

This bug was reported on IRC by @jhentula. When starting up the editor, the following exception comes up immediately and prevents him from using it completely:

Format string parameter index too big

He was unabled to use gdb because of a bug recently introduced that prevented the tool to run in Cygwin, downgrading gdb didn’t help.

We trace the issue back to shell_manager.cc:22, by making the exception return a modified version of the format that caused the issue. Now the weird thing is that the PATH variable is not empty, get_kak_binary_path() did return a proper value (the /proc/self/exe entry is correctly fetched), and we assumed that split_path was doing its job, so the issue might stem from a corner case in the format_impl function?

Either way, we couldn’t debug properly because of the gdb bug, so this will have to be reproduced somehow.

HTH.

About this issue

Original URL
State: closed
Created 8 years ago
Comments: 15 (10 by maintainers)

Most upvoted comments

Congratulations, you found a code generation bug in gcc…

In Kakoune::ShellManager::ShellManager, we have the following code:

  45bf26:   c7 04 24 48 ce 54 00    movl   $0x54ce48,(%esp)  ; 0x54ce48 is the "{}:{}" string
  45bf2d:   e8 4e 2a 09 00          call   4ee980 <Kakoune::strlen(char const*)> 
  ;; eax is the strlen return value, 5, we save that into edx
  45bf32:   89 c2                   mov    %eax,%edx
  45bf34:   8b 45 c8                mov    -0x38(%ebp),%eax 
  45bf37:   8b 4d cc                mov    -0x34(%ebp),%ecx 
  45bf3a:   89 45 a4                mov    %eax,-0x5c(%ebp) 
  45bf3d:   31 c0                   xor    %eax,%eax 
  45bf3f:   85 f6                   test   %esi,%esi 
  45bf41:   74 08                   je     45bf4b <Kakoune::ShellManager::ShellManager()+0xab> 
  45bf43:   89 34 24                mov    %esi,(%esp) 
  ;; Note that we did not save edx anywhere before that call
  ;; edx is supposed to be caller saved, so its going to get trashed
  45bf46:   e8 35 2a 09 00          call   4ee980 <Kakoune::strlen(char const*)>
  45bf4b:   89 45 dc                mov    %eax,-0x24(%ebp) 
  45bf4e:   8b 45 a4                mov    -0x5c(%ebp),%eax 
  45bf51:   89 75 d8                mov    %esi,-0x28(%ebp) 
  45bf54:   8d 75 b0                lea    -0x50(%ebp),%esi 
  45bf57:   c7 44 24 10 02 00 00    movl   $0x2,0x10(%esp) 
  45bf5e:   00  
  ;; writing the first parameter to fmt, a StringView {const char* data; int len; }
  45bf5f:   c7 44 24 04 48 ce 54    movl   $0x54ce48,0x4(%esp) ; data = "{}:{}"
  45bf66:   00  
  45bf67:   89 54 24 08             mov    %edx,0x8(%esp) ; len = edx, but edx has been trashed
  45bf6b:   89 45 e0                mov    %eax,-0x20(%ebp) 
  45bf6e:   8d 45 d8                lea    -0x28(%ebp),%eax 
  45bf71:   89 34 24                mov    %esi,(%esp) 
  45bf74:   89 4d e4                mov    %ecx,-0x1c(%ebp) 
  45bf77:   89 44 24 0c             mov    %eax,0xc(%esp) 
  ;; we call that with the fmt parameter having a bogus length
  45bf7b:   e8 e0 d3 ff ff          call   459360 <Kakoune::format(Kakoune::StringView, Kakoune::ArrayView<Kakoune::StringView const>)>

As we can see, gcc is producing incorrect assembly here, seems this only happens when generating 32 bit assembly on windows.

mawww on Nov 23, 2016