Memory crush somewhere in Socket

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 http://terrainformatica.com/htmlayout/

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

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs