Hi all.
I have a very strange and uncommon problem.
I have Ruby version 1.9 from 13 oct 2006 on Windows XP.
I use some complex library from Ruby (large .dll + C extension I’ve
written
to talk to DLL from Ruby).
All works well, but when I try using the library together with
Net::HTTP, I
have segmentation faults.
The code looks like:
Net::HTTP.get_response ‘192.168.1.1’, ‘/index.html’
SomeLibrary.call_some_method
The segfault appeared on second line, in the deeps in SomeLibrary.dll
If I not using Net::HTTP calls in first line (instead, I read something
from
local file) - all works good.
SomeLibrary’s author debugged the case and said “somebody shoot my
memory”,
like:
HEAP[ruby.exe]: HEAP: Free Heap block 33a6e48 modified at 33a6e74 after
it
was freed
I’ve debugged (through dumb commenting/uncommenting lines) that the
problem
seems to be inside socket.readline inside HTTPResponse.read_status_line
(net/http.rb, line 2017). Unfortuately, just now I have no advanced
memory
debugging tools to say something more concrete about who and how shoots
the
memory.
What can I do with this? I’d be happy to any advices!
(If it is important, SomeLibrary == HTMLayout, custom HTML layouting
engine.
It doesn’t use IE or Firefox, but it may use some Windows socket and
inet
API - can the problem lay here?)
Thanks.
V.
Victor “Zverok” Shepelev wrote:
have segmentation faults.
local file) - all works good.
debugging tools to say something more concrete about who and how shoots the
memory.
What can I do with this? I’d be happy to any advices!
(If it is important, SomeLibrary == HTMLayout, custom HTML layouting engine.
It doesn’t use IE or Firefox, but it may use some Windows socket and inet
API - can the problem lay here?)
Sounds like a reasonable guess. Also, I do not understand why a HTML
layouting lib needs sockets - especially in this case as you seem to
pull the content via Net::HTTP. IMHO layout != transport - but then
again I do not know this lib.
Good luck
robert
From: Robert K. [mailto:[email protected]]
Sent: Sunday, October 29, 2006 1:20 PM
(If it is important, SomeLibrary == HTMLayout, custom HTML layouting
engine.
It doesn’t use IE or Firefox, but it may use some Windows socket and inet
API - can the problem lay here?)
Sounds like a reasonable guess. Also, I do not understand why a HTML
layouting lib needs sockets - especially in this case as you seem to
pull the content via Net::HTTP. IMHO layout != transport - but then
again I do not know this lib.
You can look at the lib at HTMLayout – Terra Informatica Software
In short, it is not only layouting, but also url processing and loading;
main goal is Rich Applications and Occasionally Connected Computing,
thus it
provides HTTP loading also.
But the question is still actual: how can I even try to debug this? I am
semi-convinced that problem is definitely in Ruby’s extension.
v.
Hello !
Net::HTTP.get_response ‘192.168.1.1’, ‘/index.html’
SomeLibrary.call_some_method
Just out of curiosity, what happens when you swap these two calls ?
Can you actually reproduce the bug with such a simple code (and just the
loading of the libs) ? Could you post it, then ?
Vince
From: Vincent F. [mailto:[email protected]]
Sent: Sunday, October 29, 2006 3:12 PM
Net::HTTP.get_response ‘192.168.1.1’, ‘/index.html’
SomeLibrary.call_some_method
Just out of curiosity, what happens when you swap these two calls ?
The case is more general: almost each call to
SomeLibrary.almost_any_method
crushes after Net::HTTP.get once was used.
Can you actually reproduce the bug with such a simple code (and just the
loading of the libs) ?
Nope.
Could you post it, then ?
In fact, I can (none of the code is confidential). But for it be useful
for
discussion, I should also “post” a bunch of libraries.
OK, here is the program’s full text, and let’s look.
require ‘config’
require ‘htmr’
require ‘htmr/extend’
require ‘htmr/events’
require ‘net/http’
MAIN_HTMR = ‘nanobrowser.htmr’
win = Htmr::Window.create_from_file(MAIN_HTMR, ‘NanoBrowser’)
Net::HTTP.get_response ‘192.168.1.1’, ‘/index.html’ #1
node = win.get(‘#url’)
p node.window #2
Crashes at #2, if I’ll comment #1, all works as expected
Not looks very useful for understanding, yeah? :-\
V.
From: Vincent F. [mailto:[email protected]]
Sent: Sunday, October 29, 2006 3:32 PM
Net::HTTP.get_response ‘192.168.1.1’, ‘/index.html’ #1
problems in the C wrapper you did write for the library ? That’s where I
would look first…
Yep, I almost sure. I use this library alongside with wrapper last few
monthes very intensively.
But, if that’s not the case, you’ll need a debugger.
I have one (MS Visual C++). I just can’t understand, what definitely to
debug :-\ HTTP::Net sources are rather huge, and its interaction with
Socket
are not very clear to me.
V.
But, if that’s not the case, you’ll need a debugger.
I have one (MS Visual C++). I just can’t understand, what definitely to
debug :-\ HTTP::Net sources are rather huge, and its interaction with Socket
are not very clear to me.
Well, just rub your program until it triggers a memory fault, and
display a backtrace here; it might give you useful information. It might
not, as well…
For gdb, I would just use
gdb ruby
run script.rb
I don’t know how to use the MS debugger, but I expect it would be the
same…
Vince
Victor “Zverok” Shepelev wrote:
require ‘htmr/extend’
node = win.get(’#url’)
p node.window #2
Crashes at #2, if I’ll comment #1, all works as expected
Not looks very useful for understanding, yeah? :-\
Somehow puzzling… You’re sure you don’t have memory allocation
problems in the C wrapper you did write for the library ? That’s where I
would look first… But, if that’s not the case, you’ll need a debugger.
Vince