#239 too many messages to NETSEND freeze pd forever (but 0% cpu)

v0.40.1
open
nobody
puredata (322)
5
2008-02-12
2008-02-12
sistisette
No

If you send "too many" messages to netsend in zero logical time, PD immediately stops responding forever, WITHOUT eating up any cpu at all.

Attached patch illustrate the problem.
Click on the "connect" message box, and then on the [bng]

Note that it only happens if netsend is connected. If not connected, it will properly output all the "error: not connected" error messages.

Tested on Windows XP, Intel Core Duo.
PD-Vanilla 0.40.1

Discussion

  • sistisette

    sistisette - 2008-02-12
     
  • sistisette

    sistisette - 2008-02-12

    Logged In: YES
    user_id=1709568
    Originator: YES

    The problem seems to be in netreceive, not netsend.

    I have tried by eliminating the netreceive, and using another application to receive the data.
    I increased the number of message sent by a factor of 30 and no problem. Obviously netsend blocks for a considerable time, needed to send all the data (a few seconds), but then PD works normally.

    Another note: the critical amount of data needed to hang PD seems to be dependent on the total size, not the number of messages (which is not surprising), and seems to be around 32 kB (something more than 32kB indeed).

    May I guess it is an issue with some buffer that gets full?

     
  • sistisette

    sistisette - 2008-02-12

    Logged In: YES
    user_id=1709568
    Originator: YES

    File Added: SEND.pd

     
  • sistisette

    sistisette - 2008-02-12

    Logged In: YES
    user_id=1709568
    Originator: YES

    File Added: RECEIVE.pd

     
  • sistisette

    sistisette - 2008-02-12

    Logged In: YES
    user_id=1709568
    Originator: YES

    More and more and more weird.....

    Have a look at the attached SEND.pd and RECEIVE.pd

    1) Open them IN TWO SEPARATE INSTANCES OF PD

     
  • sistisette

    sistisette - 2008-02-12

    Logged In: YES
    user_id=1709568
    Originator: YES

    please ignore the previous comment, it was incomplete and i didn't mean to send it.

    I'll post the complete comment and attached files later

     
  • sistisette

    sistisette - 2008-02-12

    loop test: receive part

     
  • sistisette

    sistisette - 2008-02-12

    Logged In: YES
    user_id=1709568
    Originator: YES

    File Added: RECEIVE.pd

     
  • sistisette

    sistisette - 2008-02-12

    loop test: send part

     
  • sistisette

    sistisette - 2008-02-12

    Logged In: YES
    user_id=1709568
    Originator: YES

    File Added: SEND.pd

     
  • sistisette

    sistisette - 2008-02-12

    Logged In: YES
    user_id=1709568
    Originator: YES

    More and more and more weird.....

    Have a look at the attached SEND.pd and RECEIVE.pd

    1) Open them IN TWO SEPARATE INSTANCES OF PD

    2) Click on the [connect...( msg box on both

    3) Click on the [36000( on the SEND patch, to send 36000 messages.

    --> None of the two PD's freeze. All works fine. Note that, if the netreceive was within the same patch, 12000 messages would be sufficient to make pd freeze. Dunnow why.

    4) Now click on the [36000( on the RECEIVE patch, to send 36000 messages the other way.

    --> None of the two PD's freeze. All works fine.

    5) Now connect the [netreceive] in the RECEIVE patch to the [list prepend send] below: just where you see the comment that reads "*here*"

    6) In the SEND patch, click on the [36000( message box. Now the RECEIVE patch will be echoing back every message it receive (but the SEND patch won't, so there's no infinite loop).

    --> BOTH PD's freeze!!! They don't eat up any CPU, they simply become unresponsive.
    I can't even close them, I have to kill them. Killing any of them will "free" the other.

    7) Try playing with the number of messages sent (editing the message boxes). For some reason, the number of messages needed to freeze pd in this test is greater than the number needed to free a single instance of PD with netsend and netreceive in the same patch (bug_netsend.pd). With 36000 messages I am certain to freeze both PDs with one click.
    With about 10000 messages, it usually doesn't freeze at the first click, but if I click histerically on the message box I almost certainly have it freeze.
    This means (i guess) that the many messages don't need to be sent in zero logical times to freeze pd, they just need to be sent within a very little span of time.

    Note that I wouldn't expect netsend and netreceive to be able to handle an arbitrarily big amount of messages in an arbitrarily small time interval, but in case they can't handle it, I do expect PD to output an error or warning message, and to keep working without freezing forever.

    I had this problem in a real-life huge patch, and I had no clue of what was happening. It was just a lucky guess to investigate netsend/netreceive because I had experienced another (apparently unrelated) bug with netsend/netreceive.
    At the very least, it is a bug that PD stop working without giving the least clue of what's wrong; also, there's no need to stop execution at all. After issuing a warning and discarding overflowing messages, and possibly breaking the current message-tree being processed, PD could perfectly keep working.

     
  • Nobody/Anonymous

    Logged In: NO

    I think this bug MAY be related to bug 1891178.

    When big bursts of messages are sent through netsend, there are random message losses!!
    And the first message after a bunch of missed messages, is corrupted, namely it is truncated at the beginning.

    The handling of an invalid or incomplete messages (for example lacking a semicolon?) may be freezing netsend or netreceive?? Just a guess...

     
  • sistisette

    sistisette - 2008-02-17

    Logged In: YES
    user_id=1709568
    Originator: YES

    I guess it is NOT related to 1891178, since that bug is fixed in 0.41-2 and this one is not.

     
  • Hans-Christoph Steiner

    Logged In: YES
    user_id=27104
    Originator: NO

    I backported Miller's fixes from 0.41.

    I tested this in on Pd-0.40.3-extended-20080320 on Mac OS X 10.4/Intel and it seems to be fixed.

    It would be good to test this on Windows too.

     


Anonymous

Cancel  Add attachments





Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks