crash with very long packet for SendToSet

Issue #22 resolved
drbrain
created an issue

Copied from #91 in old bug database. I have confirmed that this bug still exists in the current version (991: b28ede61d53a).

numpf:

?py print locals()

or

?py print dir()

This generates a long string that ends up calling SendToSet with a very long (6301 for me) packet. SendToSet fails in the 11th iteration (when len -= 4800) in the memcpy call. Or so my limited understanding of gdb tells me. I don't see why this is happening. I'm assuming the "corrupt" bit at the top of the stack is some kind of normal python weirdness. (gdb) backtrace (for locals()) looks like:

{{{ 0 0xb7e56bec in memcpy () from /lib/libc.so.6 0000001 0x0805e0ef in SendToSet (set=0xb65a4ca8, data=0xb65a4b68 "\a", len=1501, flags=1) at core/net.c:2543 0000002 0x08070eec in v_send_msg (set=0xb65a4ca8, type=0 '\0', sound=0 '\0', from=0x0, str=0xb538483f "%s", ap=0xb65a4cc8 "l&65533;\023\b&65533;LZ&65533;&65533;LZ&65533;``*&65533;@\031:&65533;\230&65533;/&65533;\020") at core/chat.c:162 0000003 0x08070fc5 in SendMessage_ (p=0x8149670, str=0xb538483f "%s") at core/chat.c:178 0000004 0xb52d9d02 in pyint_method_I_CHAT_SendMessage (me=0xb52a6060, args=0xb522076c) at ../build/py_interfaces.inc:1043 0000005 0xb5378bcb in PyCFunction_Call () from /home/numpf/myzone/zone1/bin/pymod.so 0000006 0xb52a6060 in ?? () 0000007 0xb522076c in ?? () 0000008 0x00000002 in ?? () 0000009 0xb532dd3e in load_args () from /home/numpf/myzone/zone1/bin/pymod.so 0000010 0xb5221180 in ?? () 0000011 0xb52d9c94 in pyint_method_I_GROUPMAN_CheckGroupPassword (me=Cannot access memory at address 0xa ) at ../build/py_interfaces.inc:975 Backtrace stopped: previous frame inner to this frame (corrupt stack?) }}}

I should try to get this in the VC debugger.

numpf:

Not happening on windows with python 2.5 I get a BeOpen copyright message? bleh.

Back on linux, python version is 2.4.3, and it's definitely dependent on size:

numpf> ?py str = "";for x in range(0,5266): str += "a";print str # never crash numpf> ?py str = "";for x in range(0,5267): str += "a";print str # always crash

numpf:

as an obvious side note, one of these functions somewhere should break the msg up into digestable sizes.

numpf:

vsnprintf has portability issues. In glibc it's returning how much would have been written had the buffer been big enough. chat.c is assuming it's how much was written. I will investigate a portable solution and patch.

Comments (8)

  1. numpf

    hrm.. you might copy the full comment thread when "porting" bugs.

    The cause of this is that vsnprintf is non-portable. googling will show 100 different projects running into this and dealing with it different ways

  2. numpf
    • changed status to open

    edit: fix was no good. New one coming...

    I should create a new bug for creating non-truncating versions of some functions that were affected by this.

  3. Log in to comment