Hello,
If this is not the correct list to report a user error, I apologize and
will happily redirect my question where ever suitable.
I've been using cffi to make a trivial library to libsensors
https://github.com/groeck/lm-sensors and am getting an odd memory fault
error when referencing a string value from a groveled struct. After
hitting my head against a wall for a day and a half, I thought I'd ask
in case it's a simple mistake.
Here's my information:
Running a 64 bit linux install. My local version of the libsensors
library is as follows:
> elliott@desktop ~ $ file /usr/lib64/libsensors.so.4.4.0
> /usr/lib64/libsensors.so.4.4.0: ELF 64-bit LSB shared object, x86-64,
> version 1 (SYSV), dynamically linked, stripped
> elliott@desktop ~ $ sensors --version
> sensors version 3.4.0+git_83cafd29f28d463573750d897014ec7143217ae5
> with libsensors version 3.4.0+git_83cafd29f28d463573750d897014ec7143217ae5
I'm using a fairly recent version of sbcl built from source that
(apparently) passed all of the tests after the build:
> CL-USER> (lisp-implementation-version)
> "1.4.6.140-f8d5864d0"
My version of cffi appears to be the latest:
> CL-USER> (slot-value (asdf:find-system :cffi) 'asdf:version)
> "0.19.0"
My system uses cffi-grovel and defines the following structs:
> (cstruct sensors-bus-id "sensors_bus_id"
> (type "type" :type :short)
> (nr "nr" :type :short))
>
> (cstruct sensors-chip-name "sensors_chip_name"
> (prefix "prefix" :type :string)
> (bus "bus" :type (:struct sensors-bus-id))
> (address "addr" :type :int)
> (path "path" :type :string))
These are based upon the definitions in sensors/sensors.h:
https://github.com/groeck/lm-sensors/blob/master/lib/sensors.h
After asdf loading the system, the following groveler definitions are
created (had to dig these out of the cached build files):
> (cffi:defcstruct (sensors-bus-id :size 4)
> (type :short :offset 0)
> (nr :short :offset 2))
> (cl:defconstant size-of-sensors-bus-id (cffi:foreign-type-size
> '(:struct sensors-bus-id)))
> (cffi:defcstruct (sensors-chip-name :size 24)
> (prefix :string :offset 0)
> (bus (:struct sensors-bus-id) :offset 8)
> (address :int :offset 12)
> (path :string :offset 16))
> (cl:defconstant size-of-sensors-chip-name (cffi:foreign-type-size
> '(:struct sensors-chip-name)))
All of the above appears to be correct, so I proceed to load the library:
> (define-foreign-library libsensors
> (:unix (:or "libsensors.so.4" "libsensors.so"))
> (t (:default "libsensors.so")))
> (use-foreign-library libsensors)
No issues, so I define a c function from the c header file that parses a
sensor chip name-string into a struct:
> (defcfun ("sensors_parse_chip_name" cffi-sensors-parse-chip-name) :int
> "Parse a chip name to the internal representation. Return 0 on
> success, <0 on error."
> (orig-name :string)
> (res (:pointer (:struct sensors-chip-name))))
Which is based upon the following header function declaration:
> int sensors_parse_chip_name(const char *orig_name, sensors_chip_name
> *res);
Then I implement a simple call to print out the parsed values (not
including the bus):
> (defun test-sensors-parse-chip-name (string)
> (with-foreign-object (name '(:struct sensors-chip-name))
> (unless (= 0 (cffi-sensors-parse-chip-name string name))
> (error "Failed to parse: ~A" string))
> (with-foreign-slots ((prefix address path)
> name
> (:struct sensors-chip-name))
> (format t "~%Prefix: '~A'" prefix)
> (format t "~%Address: '~A'" address)
> (format t "~%Path: '~A'" path))))
The above when executed gives the following output before the error:
> CL-LMSENSORS> (test-sensors-parse-chip-name "atk0110-acpi-0")
>
> Prefix: 'atk0110'
> Address: '0'
And once it tries to access the path variable, it gives the following
error (sorry a lot rolls off the screen):
> Unhandled memory fault at #xE71B7.
> [Condition of type SB-SYS:MEMORY-FAULT-ERROR]
>
> Restarts:
> 0: [RETRY] Retry SLIME REPL evaluation request.
> 1: [*ABORT] Return to SLIME's top level.
> 2: [ABORT] abort thread (#<THREAD "repl-thread" RUNNING {1002207F93}>)
>
> Backtrace:
> 0: (CFFI::FOREIGN-STRING-LENGTH #.(SB-SYS:INT-SAP #X000E71B7)
> :ENCODING :UTF-8 :OFFSET 0)
> Locals:
> #:.DEFAULTING-TEMP. = :UTF-8
> #:.DEFAULTING-TEMP.#1 = 0
> #:N-SUPPLIED-0 = 1
> POINTER = #.(SB-SYS:INT-SAP #X000E71B7)
> 1: (FOREIGN-STRING-TO-LISP #.(SB-SYS:INT-SAP #X000E71B7) :OFFSET 0
> :COUNT NIL :MAX-CHARS 4611686018427387900 :ENCODING :UTF-8$
> Locals:
> #:.DEFAULTING-TEMP. = 0
> #:.DEFAULTING-TEMP.#1 = NIL
> #:.DEFAULTING-TEMP.#2 = 4611686018427387900
> #:.DEFAULTING-TEMP.#3 = :UTF-8
> ENCODING = :UTF-8
> #:N-SUPPLIED-0 = 1
> POINTER = #.(SB-SYS:INT-SAP #X000E71B7)
> 2: ((:METHOD TRANSLATE-FROM-FOREIGN (T CFFI::FOREIGN-STRING-TYPE))
> #.(SB-SYS:INT-SAP #X000E71B7) #<CFFI::FOREIGN-STRING-TYPE $
> 3: (TEST-SENSORS-PARSE-CHIP-NAME "atk0110-acpi-0")
My guess is I'm not defining the (:struct sensors-chip-name) correctly,
so that when sensors_parse_chip_name writes values into the struct, it
somehow overlaps into the path string.
When looking at the source for sensors_parse_chip_name I've noticed that
it does not set or access the path value at all. So I decided to write
a small c program to test the native behavior:
> elliott@desktop ~ $ cat test-sensors.c
> #include <stdio.h>
> #include <stdlib.h>
> #include "sensors/sensors.h"
>
> int main( ) {
>
> //sensors_init( NULL );
>
> struct sensors_chip_name name;
>
> int return_value = sensors_parse_chip_name( "atk0110-acpi-0", &name);
> if ( return_value != 0 ) {
> printf( "Failed to get a good return value." );
> exit( return_value );
> }
>
> printf( "Printing the prefix: '%s'\n", name.prefix );
> printf( "Address: '%i'\n", name.addr );
> printf( "Printing path value: '%s'\n", name.path );
> printf ("\n exiting..." );
>
> exit( 0 );
> }
> elliott@desktop ~ $ gcc test-sensors.c -l sensors -o test-sensors
> elliott@desktop ~ $ ./test-sensors
> Printing the prefix: 'atk0110'
> Address: '0'
> Printing path value: ''
>
> exiting...
No problems there, so I assume that the issue is all my lack of cffi-fu
training. Any pointers (yes, pun intended) would be appreciated...
sorry for such a long read, but I hope it helps to have the background.
At the very least it helped me to frame the issue in my mind by writing
this.
Regards,
Elliott
