search

osqp / OSQP.jl

Julia interface for OSQP: The Operator Splitting QP Solver
https://osqp.org/
Other
68 stars 25 forks source link

Segfault when calling dimensions on Model before setup #10

Open tkoolen opened 6 years ago

tkoolen commented 6 years ago 
julia> using OSQP

julia> m = OSQP.Model()
OSQP.Model(Ptr{OSQP.Workspace} @0x0000000000000000)

julia> OSQP.dimensions(m)

signal (11): Segmentation fault: 11
while loading no file, in expression starting on line 0
dimensions at /Users/twan/code/julia/RigidBodyDynamics/v0.6/OSQP/src/interface.jl:514
unknown function (ip: 0x11ce28e7f)
do_call at /Users/osx/buildbot/slave/package_osx64/build/src/interpreter.c:75
eval at /Users/osx/buildbot/slave/package_osx64/build/src/interpreter.c:242
jl_interpret_toplevel_expr at /Users/osx/buildbot/slave/package_osx64/build/src/interpreter.c:34
jl_toplevel_eval_flex at /Users/osx/buildbot/slave/package_osx64/build/src/toplevel.c:577
jl_toplevel_eval_in at /Users/osx/buildbot/slave/package_osx64/build/src/builtins.c:496
eval at /Applications/Julia-0.6.app/Contents/Resources/julia/lib/julia/sys.dylib (unknown line)
jlcall_eval_18039 at /Applications/Julia-0.6.app/Contents/Resources/julia/lib/julia/sys.dylib (unknown line)
eval_user_input at /Applications/Julia-0.6.app/Contents/Resources/julia/lib/julia/sys.dylib (unknown line)
jlcall_eval_user_input_20366 at /Applications/Julia-0.6.app/Contents/Resources/julia/lib/julia/sys.dylib (unknown line)
macro expansion at ./REPL.jl:97 [inlined]
#1 at ./event.jl:73
unknown function (ip: 0x11cdf344f)
jl_apply at /Users/osx/buildbot/slave/package_osx64/build/src/./julia.h:1424 [inlined]
start_task at /Users/osx/buildbot/slave/package_osx64/build/src/task.c:267
Allocations: 5426407 (Pool: 5424867; Big: 1540); GC: 10
Segmentation fault: 11
tk-sloth:OSQP twan$
tkoolen commented 6 years ago

Same with update_settings!. It would actually be quite nice to be able to set settings before calling setup!. In fact, if OSQP itself supported it, I would personally opt to remove the settings kwargs from setup! to completly separate problem-dependent data and solver settings, so as to simplify things.

bstellato commented 6 years ago

This is the same issue as in here https://github.com/oxfordcontrol/osqp/issues/39. I think the easiest solution is to add a check if the workspace is null to all the OSQP update functions in C. If the workspace is null I would return an error using the exitflag in C without generating a segfault.

I would not change the C osqp_setup interface for now because it would make things more complicated in my opinion. We can extend the Julia interface with multiple functions, but I would keep the current functions as they are to mimic the Python and Matlab interfaces.

imciner2 commented 2 years ago

This actually does look like an interface-specific issue. That backtrace (and the similar backtrace in #86) appear to be trying to directly access the structure before setup has been called using the Julia memory accessors. This will of course try to access an unallocated piece of memory since the library hasn't been initialized. There isn't anything we can do in the C library to work around that, the field accessors for the Julia wrappers should do null pointer checks to ensure the data being accessed is valid. I do see that it is checking the workspace against C_NULL already here https://github.com/osqp/OSQP.jl/blob/a173b5a3be98d74b79d7e89898f30bd9ff4f1e69/src/interface.jl#L750, so something else is needed as well.

imciner2 commented 5 months ago

Turns out this was the unsafe_load causing the segfault, not the subsequent access to the struct (which was already guarded in a null check). This was fixed in https://github.com/osqp/OSQP.jl/pull/126, but we need to audit the rest of the functions to make sure we don't try to load a null struct in any other places.