Official eMule-Board: Crash In Cemsocket - Official eMule-Board

Jump to content


  • (2 Pages)
  • +
  • 1
  • 2

Crash In Cemsocket

#1 User is offline   tHeWiZaRdOfDoS 

  • Man, what a bunch of jokers...
  • PipPipPipPipPipPipPip
  • Group: Members
  • Posts: 5630
  • Joined: 28-December 02

Posted 13 December 2005 - 09:45 AM

I got a crash while running vanilla eMule (but with SessionRatio) but can't track the reason to my code so I guess it's an error in the official code - maybe some1 knows a reason and/or solution for that...

UploadBandwidthThrottler.cpp said:

      if(socket != NULL) {
       SocketSentBytes socketSentBytes = socket->SendFileAndControlData((UINT)min(doubleSendSize, bytesToSpend-spentBytes), doubleSendSize);
       uint32 lastSpentBytes = socketSentBytes.sentBytesControlPackets + socketSentBytes.sentBytesStandardPackets;

       spentBytes += lastSpentBytes;
       spentOverhead += socketSentBytes.sentBytesControlPackets;
      } else {
       theApp.QueueDebugLogLine(false,_T("There was a NULL socket in the UploadBandwidthThrottler Standard list (equal-for-all)! Prevented usage. Index: %i Size: %i"), rememberedSlotCounter, m_StandardOrder_list.GetSize());
      }


ListenSocket.cpp said:

SocketSentBytes CClientReqSocket::SendFileAndControlData(uint32 maxNumberOfBytesToSend, uint32 overchargeMaxBytesToSend)
{
    SocketSentBytes returnStatus = CEMSocket::SendFileAndControlData(maxNumberOfBytesToSend, overchargeMaxBytesToSend);
    if (returnStatus.success && (returnStatus.sentBytesControlPackets > 0 || returnStatus.sentBytesStandardPackets > 0))
        ResetTimeOutTimer();
    return returnStatus;
}


EMSocket.cpp said:

            // We found a package to send. Get the data to send from the
            // package container and dispose of the container.
            sendblen = curPacket->GetRealPacketSize(); //CRASH
            sendbuffer = curPacket->DetachPacket();
            sent = 0;
            delete curPacket;

This post has been edited by tHeWiZaRdOfDoS: 13 December 2005 - 09:48 AM

0

#2 User is offline   Xman1 

  • Xtreme Modder
  • PipPipPipPipPipPipPip
  • Group: Members
  • Posts: 1955
  • Joined: 21-June 03

Posted 13 December 2005 - 10:09 AM

I, myself didn't get a crash.. but during the last month I got few dumps pointing to a simular problem.
in emsocket::send(..)
...
} else if(!standartpacket_queue.IsEmpty()
...
StandardPacketQueueEntry queueEntry = standartpacket_queue.RemoveHead();

crashed at red line.

it seems that the standartpacket_queue was empty when reaching the red codeline, but few lines above the IsEmpty-Test was false.

It is really a good question what's going wrong in some (very few) cases.

This post has been edited by Xman1: 13 December 2005 - 10:10 AM

0

#3 User is offline   tHeWiZaRdOfDoS 

  • Man, what a bunch of jokers...
  • PipPipPipPipPipPipPip
  • Group: Members
  • Posts: 5630
  • Joined: 28-December 02

Posted 13 December 2005 - 11:22 AM

Yeah I had that several times now, but up2now only in my personal mod so I thought it's my problem...

I can't think of anything here... socket != NULL check is there, the queue might not be empty... only thing I could imagine is that "cFos" or other packetfilters somehow drop a packet and while accessing that packet eMule would crash (I doubt it, though)
0

#4 User is offline   SlugFiller 

  • The one and only master slug
  • PipPipPipPipPipPipPip
  • Group: Members
  • Posts: 6988
  • Joined: 15-September 02

Posted 15 December 2005 - 06:29 PM

Quote

only thing I could imagine is that "cFos" or other packetfilters somehow drop a packet and while accessing that packet eMule would crash (I doubt it, though)

Uh, eMule doesn't access packets on the socket layer, these packets are standard memory buffers. External drivers could not have an impact here. Quite frankly, I wouldn't expect this sort of assertment from you.

In any way, with what Xman1 says, this is most likely a multi-threading issue. Perhaps some lock is missing when accessing the queues. In any way, I'm happy to say SFBT doesn't have such a problem, since as of recent debugging, it's proven itself quite stable.
Sorry I can't help you with ZZUL, simply not using that, and I doubt our issues are similar, since I've added my own JIT locking methods and callback methods.
Why haven't you clicked yet?

SlugFiller rule #1: Unsolicited PMs is the second most efficient method to piss me off.
SlugFiller rule #2: The first most efficient method is unsolicited eMails.
SlugFiller rule #3: If it started in a thread, it should end in the same thread.
SlugFiller rule #4: There is absolutely no reason to perform the same discussion twice in parallel, especially if one side is done via PM.
SlugFiller rule #5: Does it say "Group: Moderators" under my name? No? Then stop telling me about who you want to ban! I really don't care! Go bother a moderator.
SlugFiller rule #6: I can understand English, Hebrew, and a bit of Japanese(standard) and Chinese(mandarin), but if you speak to me in anything but English, do expect to be utterly ignored, at best.
0

#5 User is offline   tHeWiZaRdOfDoS 

  • Man, what a bunch of jokers...
  • PipPipPipPipPipPipPip
  • Group: Members
  • Posts: 5630
  • Joined: 28-December 02

Posted 15 December 2005 - 09:25 PM

Don't get that wrong - this is vanilla 0.46c Source + Slotfocus (NO ZZ codeparts - they are too complex iMHO)
And I wouldn't have supposed something like that if I hadn't encoutered it before (with NOD32s IMON)
0

#6 User is offline   SlugFiller 

  • The one and only master slug
  • PipPipPipPipPipPipPip
  • Group: Members
  • Posts: 6988
  • Joined: 15-September 02

Posted 17 December 2005 - 04:44 PM

The official source already uses ZZSF, with all of it's locking methods. A socket/throttler crash would therefore have to be ZZSF related.
Myself, I just don't trust that code. That's what SFBT is for.

You can bring these problems up with zz and see what he has to say about them. Maybe he can find a solution, as I've done for SFBT's issues.
Why haven't you clicked yet?

SlugFiller rule #1: Unsolicited PMs is the second most efficient method to piss me off.
SlugFiller rule #2: The first most efficient method is unsolicited eMails.
SlugFiller rule #3: If it started in a thread, it should end in the same thread.
SlugFiller rule #4: There is absolutely no reason to perform the same discussion twice in parallel, especially if one side is done via PM.
SlugFiller rule #5: Does it say "Group: Moderators" under my name? No? Then stop telling me about who you want to ban! I really don't care! Go bother a moderator.
SlugFiller rule #6: I can understand English, Hebrew, and a bit of Japanese(standard) and Chinese(mandarin), but if you speak to me in anything but English, do expect to be utterly ignored, at best.
0

#7 User is offline   SiRoB 

  • Retired Morph Dev
  • PipPipPipPipPipPipPip
  • Group: Members
  • Posts: 1691
  • Joined: 28-June 03

Posted 27 December 2005 - 04:15 PM

Surly ralated to

void CClientReqSocket::Disconnect(LPCTSTR pszReason){
	AsyncSelect(0);
	byConnected = ES_DISCONNECTED; <<<<<< not thread safe
	


This may happen when we are uploading and downoading with a source.
eMule 0.47c MorphXT v9.5 ::binary::source::
0

#8 User is offline   zz 

  • -
  • PipPipPipPipPipPipPip
  • Group: Debugger
  • Posts: 2014
  • Joined: 30-November 02

Posted 21 January 2006 - 10:26 PM

Quote

void CEMSocket::ClearQueues(){
    EMTrace("CEMSocket::ClearQueues on %d",(SOCKET)this);

    sendLocker.Lock();
    for(POSITION pos = controlpacket_queue.GetHeadPosition(); pos != NULL; )
        delete controlpacket_queue.GetNext(pos);
    controlpacket_queue.RemoveAll();

    for(POSITION pos = standartpacket_queue.GetHeadPosition(); pos != NULL; )
        delete standartpacket_queue.GetNext(pos).packet;
    standartpacket_queue.RemoveAll();
    sendLocker.Unlock();

    // Download (pseudo) rate control
    downloadLimit = 0;
    downloadLimitEnable = false;


I'm testing this locally.

I'm not sure that the code SiRoB refer to can cause any problem if the above is done, though. Can you talk me through the steps that would cause the problem?

/zz B)
ZZUL - get control of your uploads: ZZUL Forum
0

#9 User is offline   tHeWiZaRdOfDoS 

  • Man, what a bunch of jokers...
  • PipPipPipPipPipPipPip
  • Group: Members
  • Posts: 5630
  • Joined: 28-December 02

Posted 22 January 2006 - 11:36 AM

That's a pretty strange thing - crash mostly happens on MultiCore-CPUs but kind of randomly :(

EDIT: now I experienced a crash here:

Quote

  else if(!standartpacket_queue.IsEmpty() /*&& !onlyAllowedToSendControlPacket*/)
  {
    // There's a standard packet to send
    m_currentPacket_is_controlpacket = false;
    StandardPacketQueueEntry queueEntry = standartpacket_queue.RemoveHead();
    curPacket = queueEntry.packet;
    m_actualPayloadSize = queueEntry.actualPayloadSize;

    // remember this for statistics purposes.
    m_currentPackageIsFromPartFile = curPacket->IsFromPF();
  }

Because curPacket seemed to invalid (vanilla 0.46c + SlotFocus (disabled))

This post has been edited by tHeWiZaRdOfDoS: 22 January 2006 - 12:13 PM

0

#10 User is offline   zz 

  • -
  • PipPipPipPipPipPipPip
  • Group: Debugger
  • Posts: 2014
  • Joined: 30-November 02

Posted 22 January 2006 - 04:36 PM

That could happen if you don't have my fix above.

/zz B)
ZZUL - get control of your uploads: ZZUL Forum
0

#11 User is offline   Xman1 

  • Xtreme Modder
  • PipPipPipPipPipPipPip
  • Group: Members
  • Posts: 1955
  • Joined: 21-June 03

Posted 22 January 2006 - 05:06 PM

@zz
I don't know how Sirobs situation can occur... but also I don't know how the situation can occur when your patch is needed. Do you have any explanation ?

btw. I got few dumps pointing to a crash in AsyncsocketEx.. when a socket is detached in OnClose
0

#12 User is offline   zz 

  • -
  • PipPipPipPipPipPipPip
  • Group: Debugger
  • Posts: 2014
  • Joined: 30-November 02

Posted 22 January 2006 - 10:14 PM

Xman: The packet lists may be emptied/deleted while the critical section inside Send uses those very lists.

/zz B)

This post has been edited by zz: 22 January 2006 - 10:43 PM

ZZUL - get control of your uploads: ZZUL Forum
0

#13 User is offline   Xman1 

  • Xtreme Modder
  • PipPipPipPipPipPipPip
  • Group: Members
  • Posts: 1955
  • Joined: 21-June 03

Posted 22 January 2006 - 10:31 PM

???
there is no problem if the packet-lists are empty and we are inside Send. The problem is, the lists may not be emptied while we are inside send.
The question is: in which case it can happen that ClearQueues is called while we are inside Send ? I don't see how this can happen... but crash-dumps shows that is can happen. But how ?
0

#14 User is offline   zz 

  • -
  • PipPipPipPipPipPipPip
  • Group: Debugger
  • Posts: 2014
  • Joined: 30-November 02

Posted 22 January 2006 - 10:44 PM

I corrected my post above to hopefully make it a little more legible.

/zz B)
ZZUL - get control of your uploads: ZZUL Forum
0

#15 User is offline   Xman1 

  • Xtreme Modder
  • PipPipPipPipPipPipPip
  • Group: Members
  • Posts: 1955
  • Joined: 21-June 03

Posted 22 January 2006 - 10:53 PM

ok :)
But I I don't find an answer in which ituation/how this can occur. :flowers:
0

#16 User is offline   SiRoB 

  • Retired Morph Dev
  • PipPipPipPipPipPipPip
  • Group: Members
  • Posts: 1691
  • Joined: 28-June 03

Posted 22 January 2006 - 11:05 PM

by the way move the sendLocker.Lock() to the top in the UploadBandwidthThrottler::RunInternal()

m_StandardOrder_list could be changed and reduced. ;)

@Xman1 it could happen when we never reach by the ES_CONNECTED State ;)
I guess we could remove some lock by checking proper state in some place.

P.S.: We are going get it stable back :clap:
eMule 0.47c MorphXT v9.5 ::binary::source::
0

#17 User is offline   tHeWiZaRdOfDoS 

  • Man, what a bunch of jokers...
  • PipPipPipPipPipPipPip
  • Group: Members
  • Posts: 5630
  • Joined: 28-December 02

Posted 23 January 2006 - 09:07 AM

SiRoB, on Jan 23 2006, 12:05 AM, said:

by the way move the sendLocker.Lock() to the top in the UploadBandwidthThrottler::RunInternal()

m_StandardOrder_list could be changed and reduced. ;)

Where exactly should that be? I can't see access to m_StandardOrder_list in the latest official release (0.46c)


EDIT: @ZZ: I already hat that patch I proposed in... so it must be something different

This post has been edited by tHeWiZaRdOfDoS: 23 January 2006 - 09:43 AM

0

#18 User is offline   SiRoB 

  • Retired Morph Dev
  • PipPipPipPipPipPipPip
  • Group: Members
  • Posts: 1691
  • Joined: 28-June 03

Posted 23 January 2006 - 01:21 PM

tHeWiZaRdOfDoS, on Jan 23 2006, 11:07 AM, said:

SiRoB, on Jan 23 2006, 12:05 AM, said:

by the way move the sendLocker.Lock() to the top in the UploadBandwidthThrottler::RunInternal()

m_StandardOrder_list could be changed and reduced. ;)

Where exactly should that be? I can't see access to m_StandardOrder_list in the latest official release (0.46c)

View Post
I mean in the 0.47a BETA.
eMule 0.47c MorphXT v9.5 ::binary::source::
0

#19 User is offline   zz 

  • -
  • PipPipPipPipPipPipPip
  • Group: Debugger
  • Posts: 2014
  • Joined: 30-November 02

Posted 23 January 2006 - 05:48 PM

Quote

        // check busy level for all the slots (WSAEWOULDBLOCK status)
        uint32 cBusy = 0;
        uint32 nCanSend = 0;

        sendLocker.Lock();
        for (int i = 0; i < m_StandardOrder_list.GetSize() && (i < 3 || (UINT)i < GetSlotLimit(theApp.uploadqueue->GetDatarate())); i++){
            if (m_StandardOrder_list[i] != NULL && m_StandardOrder_list[i]->HasQueues()) {
                nCanSend++;

                if(m_StandardOrder_list[i]->IsBusy())
                    cBusy++;
            }
        }
        sendLocker.Unlock();


Sirob, I think this would be a temporary fix for that. The other two accesses (m_StandardOrder_list.GetSize()) can probably stay outside the critical section safely, and we don't want the call to sleep() inside the lock.

I would prefer to only lock once per loop, but that would need a bigger change and need more analyzing.

At times like this I wish I had a multi cpu machine. :flowers:

How well/bad does the 0.47a beta work on your multi cpu machine compared with 0.46c?

/zz B)

This post has been edited by zz: 23 January 2006 - 05:50 PM

ZZUL - get control of your uploads: ZZUL Forum
0

#20 User is offline   SiRoB 

  • Retired Morph Dev
  • PipPipPipPipPipPipPip
  • Group: Members
  • Posts: 1691
  • Joined: 28-June 03

Posted 24 January 2006 - 03:10 PM

zz, on Jan 23 2006, 07:48 PM, said:

How well/bad does the 0.47a beta work on your multi cpu machine compared with 0.46c?

/zz B)
View Post
Well in fact, i can't tell you as i'm using my mod based on it with those various sendlock.
The only thing i can tell you is that i encounter no more trouble.
eMule 0.47c MorphXT v9.5 ::binary::source::
0

  • Member Options

  • (2 Pages)
  • +
  • 1
  • 2

1 User(s) are reading this topic
0 members, 1 guests, 0 anonymous users