crash with very long packet for SendToSet

Issue #22 resolved
created an issue

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


?py print locals()


?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/ 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/ 0000005 0xb5378bcb in PyCFunction_Call () from /home/numpf/myzone/zone1/bin/ 0000006 0xb52a6060 in ?? () 0000007 0xb522076c in ?? () 0000008 0x00000002 in ?? () 0000009 0xb532dd3e in load_args () from /home/numpf/myzone/zone1/bin/ 0000010 0xb5221180 in ?? () 0000011 0xb52d9c94 in pyint_method_I_GROUPMAN_CheckGroupPassword (me=Cannot access memory at address 0xa ) at ../build/ Backtrace stopped: previous frame inner to this frame (corrupt stack?) }}}

I should try to get this in the VC debugger.


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


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


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