Asp Forum - Memory crush somewhere in Socket

Victor 'Zverok' Shepelev

10/29/2006 9:47:00 AM

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.

7 Answers

Robert Klemme

10/29/2006 11:16:00 AM

Victor "Zverok" Shepelev wrote:
> 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

10/29/2006 12:45:00 PM

From: Robert Klemme [mailto:shortcutter@googlemail.com]
Sent: Sunday, October 29, 2006 1:20 PM
>> 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.

You can look at the lib at http://terrainformatica.com/...

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

10/29/2006 1:12:00 PM

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

--
Vincent Fourmond, PhD student
http://vincent.fourmon...

Victor 'Zverok' Shepelev

10/29/2006 1:23:00 PM

From: Vincent Fourmond [mailto:vincent.fourmond@9online.fr]
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.

Vincent Fourmond

10/29/2006 1:32:00 PM

Victor "Zverok" Shepelev wrote:
>> 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? :-
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
--
Vincent Fourmond, PhD student
http://vincent.fourmon...

Victor 'Zverok' Shepelev

10/29/2006 1:38:00 PM

From: Vincent Fourmond [mailto:vincent.fourmond@9online.fr]
Sent: Sunday, October 29, 2006 3:32 PM
>Victor "Zverok" Shepelev wrote:
>>> 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? :->
> 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

10/29/2006 4:47:00 PM

>> 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
--
Vincent Fourmond, PhD student
http://vincent.fourmon...

comp.lang.ruby

Memory crush somewhere in Socket

Victor 'Zverok' Shepelev

Robert Klemme

Victor 'Zverok' Shepelev

Vincent Fourmond

Victor 'Zverok' Shepelev

Vincent Fourmond

Victor 'Zverok' Shepelev

Vincent Fourmond

x Login to ForumsZone