Memory crush somewhere in Socket

[Victor \Zverok\ Shepelev]

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.

 

[Robert Klemme]

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?)

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

 

[Victor \Zverok\ Shepelev]

From: Robert Klemme [mailto:[email protected]]
Sent: Sunday, October 29, 2006 1:20 PM

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.

 

[Vincent Fourmond]

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

 

[Victor \Zverok\ Shepelev]

From: Vincent Fourmond [mailto:[email protected]]
Sent: Sunday, October 29, 2006 3:12 PM

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.

 

[Vincent Fourmond]

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? :-\

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

 

[Victor \Zverok\ Shepelev]

From: Vincent Fourmond [mailto:[email protected]]
Sent: Sunday, October 29, 2006 3:32 PM

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...

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.

 

[Vincent Fourmond]

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