I was trying to fix the busy_handler of the sqlite3. (version 1.1.0
makes
the interpreter crash)
Rewriting busy_handler in lib/sqlite3/native/driver.rb from
def busy_handler( db, data=nil, &block )
if block
cb = API::CallbackData.new
cb.proc = block
cb.data = data
end
API.sqlite3_busy_handler( db,
block ? API::Sqlite3_ruby_busy_handler : nil, cb )
end
to
def busy_handler( db, data=nil, &block )
if block
cb = API::CallbackData.new
cb.proc = block
cb.data = data
API.sqlite3_busy_handler( db, API::Sqlite3_ruby_busy_handler,
cb)
else
API.sqlite3_busy_handler( db, nil, nil)
end
end
fixed the problem (at least on my system)
For me, those two functions are strictly equivalent. So … where’s the
difference ?
For me, those two functions are strictly equivalent. So …
where’s the difference ?
If you call the first busy_handler without a block, cb isn’t
declared when calling Sqlite3_ruby_busy_handler.
gegroet,
Erik V. - http://www.erikveen.dds.nl/
For me, those two functions are strictly equivalent. So
… where’s the difference ?
If you call the first busy_handler without a block, cb
isn’t declared when calling Sqlite3_ruby_busy_handler.
Does not seem so … The code does run. The problem is a
crash (i.e. segfault).
You asked about the difference between the two functions, not
why you application crashed ;)…
gegroet,
Erik V. - http://www.erikveen.dds.nl/
“S” == Sylvain J. [email protected] writes:
S> Does not seem so … The code does run. The problem is a crash
(i.e.
S> segfault).
I don’t know what is a crash. Can you give a small example to
reproduce
the problem, and your ruby version.
Guy Decoux