Linux 32 bits build is broken #95

Closed
jeandudey opened this Issue Jan 20, 2017 · 27 comments

Projects

None yet

3 participants

@jeandudey
Contributor

Debug:

Starting program: /home/jeandudey/rust-projects/remacs/src/temacs --batch --loadup bootstrap
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x0822d1b2 in remacs::lists::XCAR (object=LispObject = {...}) at /home/jeandudey/rust-projects/remacs/rust_src/src/lists.rs:151
151	    (*XCONS(object)).car
(gdb) bt
#0  0x0822d1b2 in remacs::lists::XCAR (object=LispObject = {...}) at /home/jeandudey/rust-projects/remacs/rust_src/src/lists.rs:151
#1  0x0822d291 in remacs::lists::car (object=LispObject = {...}) at /home/jeandudey/rust-projects/remacs/rust_src/src/lists.rs:166
#2  0x0822d454 in remacs::lists::Fcar (list=LispObject = {...}) at /home/jeandudey/rust-projects/remacs/rust_src/src/lists.rs:185
#3  0x081aa768 in print_error_message (data=<optimized out>, stream=<optimized out>, context=<optimized out>, caller=<optimized out>) at print.c:907
#4  0x081aaa2c in Ferror_message_string (obj=140488155) at print.c:868
#5  0x0818f827 in signal_or_quit (error_symbol=error_symbol@entry=26328, data=140488155, data@entry=140488139, keyboard_quit=keyboard_quit@entry=false) at eval.c:1603
#6  0x0818fb82 in Fsignal (error_symbol=26328, data=140488139) at eval.c:1483
#7  0x081901bc in xsignal (data=<optimized out>, error_symbol=26328) at lisp.h:3817
#8  0x081901bc in xsignal2 (error_symbol=26328, arg1=-1073749392, arg2=16056) at eval.c:1624
#9  0x0817b0e5 in wrong_type_argument (predicate=-1073749392, value=16056) at data.c:152
#10 0x0822d310 in remacs::lists::car (object=LispObject = {...}) at /home/jeandudey/rust-projects/remacs/rust_src/src/lists.rs:170
#11 0x0822d454 in remacs::lists::Fcar (list=LispObject = {...}) at /home/jeandudey/rust-projects/remacs/rust_src/src/lists.rs:185
#12 0x081aa768 in print_error_message (data=<optimized out>, stream=<optimized out>, context=<optimized out>, caller=<optimized out>) at print.c:907
#13 0x081aaa2c in Ferror_message_string (obj=140488123) at print.c:868
#14 0x0818f827 in signal_or_quit (error_symbol=error_symbol@entry=26328, data=140488123, data@entry=140488107, keyboard_quit=keyboard_quit@entry=false) at eval.c:1603
#15 0x0818fb82 in Fsignal (error_symbol=26328, data=140488107) at eval.c:1483
#16 0x081901bc in xsignal (data=<optimized out>, error_symbol=26328) at lisp.h:3817
#17 0x081901bc in xsignal2 (error_symbol=26328, arg1=-1073748896, arg2=16056) at eval.c:1624
#18 0x0817b0e5 in wrong_type_argument (predicate=-1073748896, value=16056) at data.c:152
#19 0x0822d310 in remacs::lists::car (object=LispObject = {...}) at /home/jeandudey/rust-projects/remacs/rust_src/src/lists.rs:170
#20 0x0822d454 in remacs::lists::Fcar (list=LispObject = {...}) at /home/jeandudey/rust-projects/remacs/rust_src/src/lists.rs:185
#21 0x081aa768 in print_error_message (data=<optimized out>, stream=<optimized out>, context=<optimized out>, caller=<optimized out>) at print.c:907
#22 0x081aaa2c in Ferror_message_string (obj=140488091) at print.c:868
#23 0x0818f827 in signal_or_quit (error_symbol=error_symbol@entry=26328, data=140488091, data@entry=140488075, keyboard_quit=keyboard_quit@entry=false) at eval.c:1603
#24 0x0818fb82 in Fsignal (error_symbol=26328, data=140488075) at eval.c:1483
#25 0x081901bc in xsignal (data=<optimized out>, error_symbol=26328) at lisp.h:3817
#26 0x081901bc in xsignal2 (error_symbol=26328, arg1=-1073748400, arg2=16056) at eval.c:1624
#27 0x0817b0e5 in wrong_type_argument (predicate=-1073748400, value=16056) at data.c:152
#28 0x0822d310 in remacs::lists::car (object=LispObject = {...}) at /home/jeandudey/rust-projects/remacs/rust_src/src/lists.rs:170
#29 0x0822d454 in remacs::lists::Fcar (list=LispObject = {...}) at /home/jeandudey/rust-projects/remacs/rust_src/src/lists.rs:185
#30 0x081aa768 in print_error_message (data=<optimized out>, stream=<optimized out>, context=<optimized out>, caller=<optimized out>) at print.c:907
#31 0x081aaa2c in Ferror_message_string (obj=140488059) at print.c:868
#32 0x0818f827 in signal_or_quit (error_symbol=error_symbol@entry=26328, data=140488059, data@entry=140488043, keyboard_quit=keyboard_quit@entry=false) at eval.c:1603
#33 0x0818fb82 in Fsignal (error_symbol=26328, data=140488043) at eval.c:1483
#34 0x081901bc in xsignal (data=<optimized out>, error_symbol=26328) at lisp.h:3817
#35 0x081901bc in xsignal2 (error_symbol=26328, arg1=-1073747904, arg2=16056) at eval.c:1624
#36 0x0817b0e5 in wrong_type_argument (predicate=-1073747904, value=16056) at data.c:152
#37 0x0822d310 in remacs::lists::car (object=LispObject = {...}) at /home/jeandudey/rust-projects/remacs/rust_src/src/lists.rs:170
#38 0x0822d454 in remacs::lists::Fcar (list=LispObject = {...}) at /home/jeandudey/rust-projects/remacs/rust_src/src/lists.rs:185
#39 0x081aa768 in print_error_message (data=<optimized out>, stream=<optimized out>, context=<optimized out>, caller=<optimized out>) at print.c:907
#40 0x081aaa2c in Ferror_message_string (obj=140488027) at print.c:868
#41 0x0818f827 in signal_or_quit (error_symbol=error_symbol@entry=26328, data=140488027, data@entry=140488011, keyboard_quit=keyboard_quit@entry=false) at eval.c:1603
---Type <return> to continue, or q <return> to quit---
#42 0x0818fb82 in Fsignal (error_symbol=26328, data=140488011) at eval.c:1483
#43 0x081901bc in xsignal (data=<optimized out>, error_symbol=26328) at lisp.h:3817
#44 0x081901bc in xsignal2 (error_symbol=26328, arg1=-1073747408, arg2=16056) at eval.c:1624
#45 0x0817b0e5 in wrong_type_argument (predicate=-1073747408, value=16056) at data.c:152
#46 0x0822d310 in remacs::lists::car (object=LispObject = {...}) at /home/jeandudey/rust-projects/remacs/rust_src/src/lists.rs:170
#47 0x0822d454 in remacs::lists::Fcar (list=LispObject = {...}) at /home/jeandudey/rust-projects/remacs/rust_src/src/lists.rs:185
#48 0x081aa768 in print_error_message (data=<optimized out>, stream=<optimized out>, context=<optimized out>, caller=<optimized out>) at print.c:907
#49 0x081aaa2c in Ferror_message_string (obj=140487995) at print.c:868
#50 0x0818f827 in signal_or_quit (error_symbol=error_symbol@entry=26328, data=140487995, data@entry=140487979, keyboard_quit=keyboard_quit@entry=false) at eval.c:1603
#51 0x0818fb82 in Fsignal (error_symbol=26328, data=140487979) at eval.c:1483
#52 0x081901bc in xsignal (data=<optimized out>, error_symbol=26328) at lisp.h:3817
#53 0x081901bc in xsignal2 (error_symbol=26328, arg1=-1073746912, arg2=16056) at eval.c:1624
#54 0x0817b0e5 in wrong_type_argument (predicate=-1073746912, value=16056) at data.c:152
#55 0x0822d310 in remacs::lists::car (object=LispObject = {...}) at /home/jeandudey/rust-projects/remacs/rust_src/src/lists.rs:170
#56 0x0822d454 in remacs::lists::Fcar (list=LispObject = {...}) at /home/jeandudey/rust-projects/remacs/rust_src/src/lists.rs:185
#57 0x081aa768 in print_error_message (data=<optimized out>, stream=<optimized out>, context=<optimized out>, caller=<optimized out>) at print.c:907
#58 0x081aaa2c in Ferror_message_string (obj=140487963) at print.c:868
#59 0x0818f827 in signal_or_quit (error_symbol=error_symbol@entry=26328, data=140487963, data@entry=140487947, keyboard_quit=keyboard_quit@entry=false) at eval.c:1603
#60 0x0818fb82 in Fsignal (error_symbol=26328, data=140487947) at eval.c:1483
#61 0x081901bc in xsignal (data=<optimized out>, error_symbol=26328) at lisp.h:3817
#62 0x081901bc in xsignal2 (error_symbol=26328, arg1=-1073746416, arg2=16056) at eval.c:1624
#63 0x0817b0e5 in wrong_type_argument (predicate=-1073746416, value=16056) at data.c:152
#64 0x0822d400 in remacs::lists::cdr (object=LispObject = {...}) at /home/jeandudey/rust-projects/remacs/rust_src/src/lists.rs:179
#65 0x0822d4b4 in remacs::lists::Fcdr (list=LispObject = {...}) at /home/jeandudey/rust-projects/remacs/rust_src/src/lists.rs:206
#66 0x081414e0 in Fget_buffer_create (buffer_or_name=137842796) at buffer.c:509
#67 0x081459d5 in init_buffer_once () at buffer.c:5234
#68 0x0805d20c in main (argc=<optimized out>, argv=<optimized out>) at emacs.c:1172

@jeandudey
Contributor

The SIGSEGV is generated in Fget_buffer at the return statement when Fcdris called.

@jeandudey
Contributor

a more detailed backtrace:

#0  0x0822d254 in remacs::lists::car (object=LispObject = {...}) at /home/jeandudey/rust-projects/remacs/rust_src/src/lists.rs:164
#1  0x0822d454 in remacs::lists::Fcar (list=LispObject = {...}) at /home/jeandudey/rust-projects/remacs/rust_src/src/lists.rs:185
#2  0x081aa768 in print_error_message (data=<optimized out>, stream=<optimized out>, context=<optimized out>, caller=<optimized out>) at print.c:907
#3  0x081aaa2c in Ferror_message_string (obj=140496155) at print.c:868
#4  0x0818f827 in signal_or_quit (error_symbol=error_symbol@entry=26328, data=140496155, data@entry=140496139, keyboard_quit=keyboard_quit@entry=false) at eval.c:1603
#5  0x0818fb82 in Fsignal (error_symbol=26328, data=140496139) at eval.c:1483
#6  0x081901bc in xsignal (data=<optimized out>, error_symbol=26328) at lisp.h:3817
#7  0x081901bc in xsignal2 (error_symbol=26328, arg1=-1073746368, arg2=16056) at eval.c:1624
#8  0x0817b0e5 in wrong_type_argument (predicate=-1073746368, value=16056) at data.c:152
#9  0x0822d400 in remacs::lists::cdr (object=LispObject = {...}) at /home/jeandudey/rust-projects/remacs/rust_src/src/lists.rs:179
#10 0x0822d4b4 in remacs::lists::Fcdr (list=LispObject = {...}) at /home/jeandudey/rust-projects/remacs/rust_src/src/lists.rs:206
#11 0x081414e0 in Fget_buffer_create (buffer_or_name=137842796) at buffer.c:509
#12 0x081459d5 in init_buffer_once () at buffer.c:5234
#13 0x0805d20c in main (argc=<optimized out>, argv=<optimized out>) at emacs.c:1172

The SIGSEVG is generated in remacs::lists::car when trying to dereference XCONS.

@jeandudey
Contributor

The root of the error is in when Fcar is called and calls wrong_type_argument.

@jeandudey
Contributor

The error is introduced by #62, before that, temacs runs normally.

@Wilfred
Owner
Wilfred commented Jan 21, 2017

It's possible that cons cell detection was broken due to incorrect handling of USE_LSB_TAG. @jeandudey can you confirm you're still seeing this now #97 has been merged?

We should also look at a 32-bit build on Travis.

@jeandudey
Contributor

Let me verify.

@jeandudey
Contributor
jeandudey commented Jan 21, 2017 edited

@Wilfred still segfaults

@jeandudey
Contributor
jeandudey commented Jan 21, 2017 edited

I don't think USE_LSB_TAG is the problem because a call to LispObject::get_type is made before that and gives the correct result (specifically when CHECK_STRING is called in Fget_buffer) .

@Wilfred Wilfred added a commit that referenced this issue Jan 21, 2017
@Wilfred 32 bit build on Travis [wip]
Should help with #95
9fc26af
@Wilfred Wilfred added a commit that referenced this issue Jan 21, 2017
@Wilfred 32 bit build on Travis [wip]
Should help with #95
b99bb35
@rogermarlow
Contributor

This issue is looking quite like #38 that MacOS systems are having i.e. problem with the Fcdr implementation.

@jeandudey
Contributor

@Wilfred reversing changes made by #62 solves the segfault, but i found a new crazy segfault:

(gdb) run
Starting program: /home/jeandudey/rust-projects/remacs/src/temacs 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x085fdd8b in bss_sbrk_buffer ()
(gdb) bt
#0  0x085fdd8b in bss_sbrk_buffer ()
#1  0x00002790 in  ()
#2  0x085fdd93 in bss_sbrk_buffer ()
#3  0x00000000 in  ()

I will investigate what can be causing that.

@jeandudey
Contributor

The other segfault was generated on syms_of_keyboard which was calling Fsetcdr, i've ported it to C again and the segfault disappeared, i still don't know why.

@jeandudey
Contributor
jeandudey commented Jan 25, 2017 edited
@Wilfred
Owner
Wilfred commented Jan 25, 2017

@jeandudey it's possible that we have the wrong value for Qnil on 32 bit Linux. If you just define Qnil as an extern pub static, does the issue still occur?

@Wilfred
Owner
Wilfred commented Jan 28, 2017

Playing with this today, I've noticed that we're infinitely recursing in Fcar on 32-bit linux.

I've also tried defining Qnil as an extern, but that doesn't fix this.

@jeandudey
Contributor

@Wilfred yes, but that's the result of Fcdr calling wrong_type_argument.

@Wilfred
Owner
Wilfred commented Jan 28, 2017

Poking at this further, the Fcdr is called from:

return Fcdr (assoc_ignore_text_properties (buffer_or_name, Vbuffer_alist));

Weirdly, Vbuffer_alist is nil but Fcdr is not being passed a nil value by the looks of things:

(gdb) p Vbuffer_alist
$6 = 0
(gdb) p NILP(Vbuffer_alist)
$7 = true
(gdb) down
#0  remacs::lists::Fcdr (list=...) at /home/wilfred/projects/remacs/src/../rust_src/src/lists.rs:208
208         cdr(list)
(gdb) p NILP(list)
$8 = false
@jeandudey
Contributor
jeandudey commented Jan 28, 2017 edited

@Wilfred that's what i experienced, i solved it making the return of assoc_ignore_text_properties volatile like so:

...
volatile Lisp_Object assoc = assoc_ignore_text_properties (buffer_or_name, Vbuffer_alist);
return Fcdr(assoc);

And it passed Qnil magically, but after that another segfault originates in remacs::lists::cdr when returning Qnil.

@Wilfred
Owner
Wilfred commented Jan 28, 2017

Ha, I ended up doing something very similar:

volatile Lisp_Object res = assoc_ignore_text_properties (buffer_or_name, Vbuffer_alist);
return Fcdr (res);

but I don't see Qnil being passed correctly:

gdb) p res
$19 = 0
(gdb) p NILP(res)
$20 = true
(gdb) down
#0  remacs::lists::Fcdr (list=...) at /home/wilfred/projects/remacs/src/../rust_src/src/lists.rs:206
(gdb) p list
$21 = {__0 = 140372000}
(gdb) p NILP(list)
$22 = false
@Wilfred
Owner
Wilfred commented Jan 28, 2017

All the values in definitions.rs generated by build.rs seem to be correct, but I'm still wondering whether we're treating a type as the wrong size somewhere.

@Wilfred
Owner
Wilfred commented Jan 29, 2017 edited

As far as I can tell, the parameter is being passed correctly:

   |0x814161d <Fget_buffer+61>      push   %eax
   |0x814161e <Fget_buffer+62>      call   0x822a190 <remacs::lists::Fcdr>   

$eax is 0 at this point. However, Fcdr isn't accessing the same location on the stack. I'm wondering if it's to do with the fact we define LispObject as a struct.

@Wilfred
Owner
Wilfred commented Jan 29, 2017

OK, so it was #49 that broke this. #62 just made the problem visible I think.

@jeandudey
Contributor

Compiling with --enable-check-lisp-object-type solved the segfault but there's still another issue:

./temacs --batch  --load loadup bootstrap
Loading loadup.el (source)...
Using load-path (/home/jeandudey/rust-projects/remacs/lisp /home/jeandudey/rust-projects/remacs/lisp/emacs-lisp /home/jeandudey/rust-projects/remacs/lisp/language /home/jeandudey/rust-projects/remacs/lisp/international /home/jeandudey/rust-projects/remacs/lisp/textmodes /home/jeandudey/rust-projects/remacs/lisp/vc)
Loading emacs-lisp/byte-run (source)...
Symbol’s function definition is void: declare

What does it mean?

@Wilfred
Owner
Wilfred commented Jan 29, 2017

I believe it's trying to execute this:

(defmacro defun (name arglist &optional docstring &rest body)
  "Define NAME as a function.
The definition is (lambda ARGLIST [DOCSTRING] BODY...).
See also the function `interactive'.
DECL is a declaration, optional, of the form (declare DECLS...) where
DECLS is a list of elements of the form (PROP . VALUES).  These are
interpreted according to `defun-declarations-alist'.
The return value is undefined.

\(fn NAME ARGLIST &optional DOCSTRING DECL &rest BODY)"
  ;; We can't just have `decl' as an &optional argument, because we need
  ;; to distinguish
  ;;    (defun foo (arg) (toto) nil)
  ;; from
  ;;    (defun foo (arg) (toto)).
  (declare (doc-string 3) (indent 2))
  ...

if you comment out the declare form here, you get a nasty segfault with a totally bogus LispSubr. I think the best solution is to go back to type Lisp_Object = EmacsInt. This is faster on 32-bit linux, and should work.

@jeandudey
Contributor

I think we should have separate types for dealing with FFI, we should have a type called Lisp_Object for FFI functions and a wrapper one called LispObject to make code more safe. So in a FFI function you would construct a LispObject like so:

// Note the underscore for the FFI type
pub extern "C" Fmy_fn(data: Lisp_Object) {
    let data = LispObject::from_raw(data);
    ...
    // returning
    some_result.into_raw()
}
@Wilfred
Owner
Wilfred commented Jan 29, 2017

There's not much pure-Rust logic yet, and I'm worried that it's really easy to screw up (on my rust-lang example repo, I don't get any warnings!).

We could use build.rs to define Lisp_Object as a tuple struct on 64-bit platforms, and a type alias otherwise. At that point we're reinventing --enable-check-lisp-object-type in Rust, for better or worse.

@jeandudey
Contributor

I think having both separate types would be much cleaner and can be done without merging #121.

Also it would create a layer between C code and Rust code.

@jeandudey jeandudey closed this Feb 19, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment