Tox protocol

[Corak]

Ok, sorry. Thanks. Updating now.

Excellent! 
Now it seems almost crashless and much more stable. Standard methods of disconnection now not crashing anymore.

[Wishmaster]

Not with Tox! Stop posting them over and over again....

[Corak]

Ok, i know. Removed it from there.
Anyway sometimes I can give some more details and netlog on some repeating old crash, so I will post now only addition info about them.
____________
+

Got New tox crash on "do_onion_client". Netlog in attach:

http://trac.miranda-ng.org/ticket/1035

do_onion_client

Code: [Select]

Exception: Access Violation at address 13DCAD91. Reading from address 092DA038.

Stack Trace:
---------------------------------------------------------------
13DCAD91 (libtox 13DA0000): ..\toxcore\onion_client.c (1435): do_onion_client
1224C554 (mir_core 12240000): e:\sources\miranda_ng_compilation\src\mir_core\src\threads.cpp (154): forkthreadex_r
78AFC556 (MSVCR100 78AA0000): (filename not available) (0): endthreadex
78AFC600 (MSVCR100 78AA0000): (filename not available) (0): endthreadex
7C80B729 (kernel32 7C800000): (filename not available) (0): GetModuleFileNameA


[close]

Dont know it was reconnection or not. It's happened just in the middle of some active talk by other protocols (MSN/Vk)...
____________________________________________________________________________________________

*

Repeated Old Crash on "toxcore\ping_array.c: ping_array_add" . Netlog added.

http://trac.miranda-ng.org/ticket/1036
______________________________________________________________________________________________

+? Got New(?) Crash on "mutex_ref":

http://trac.miranda-ng.org/ticket/1038

mutex_ref

Code: [Select]

Exception: Access Violation at address 13E8A445. Reading from address 020C01CB.

Stack Trace:
---------------------------------------------------------------
13E8A445 (libtox 13DA0000): ..\..\mingw-w64-libraries\winpthreads\src\mutex.c (83): mutex_ref
1224C554 (mir_core 12240000): e:\sources\miranda_ng_compilation\src\mir_core\src\threads.cpp (154): forkthreadex_r
78AFC556 (MSVCR100 78AA0000): (filename not available) (0): endthreadex
78AFC600 (MSVCR100 78AA0000): (filename not available) (0): endthreadex
7C80B729 (kernel32 7C800000): (filename not available) (0): GetModuleFileNameA

[close]

___________________________

+
New crash on "tox_core.cpp: InitToxCore"
Netlog added.

http://trac.miranda-ng.org/ticket/1039

InitToxCore

Code: [Select]

Likely cause of the crash plugin: Tox protocol

Exception: Access Violation at address 1720FCAE. Writing to address 00000000.

Stack Trace:
---------------------------------------------------------------
1720FCAE (Tox 17200000): e:\sources\miranda_ng_compilation\protocols\tox\src\tox_core.cpp (55): CToxProto::InitToxCore
1720C3C7 (Tox 17200000): e:\sources\miranda_ng_compilation\protocols\tox\src\tox_network.cpp (154): CToxProto::PollingThread
1224C554 (mir_core 12240000): e:\sources\miranda_ng_compilation\src\mir_core\src\threads.cpp (154): forkthreadex_r
78AFC556 (MSVCR100 78AA0000): (filename not available) (0): endthreadex
78AFC600 (MSVCR100 78AA0000): (filename not available) (0): endthreadex
7C80B729 (kernel32 7C800000): (filename not available) (0): GetModuleFileNameA


[close]

________________________________________

*
Repeated crash on "msvcrt: memcmp" (Seems tox related too. It happened much times when I disabled/enabled Tox account or on reconnection.).
Added Netlog

http://trac.miranda-ng.org/ticket/1022#comment:2

memcmp

Code: [Select]

Exception: Access Violation at address 77C36F07. Reading from address 064AB290.

Stack Trace:
---------------------------------------------------------------
77C36F07 (msvcrt 77C00000): (filename not available) (0): memcmp

[close]

Post Merge: 25 09 2015, 22:29:15+ New Tox crash "group.c: do_groupchats"

http://trac.miranda-ng.org/ticket/1052

do_groupchats[code

Exception: Access Violation at address 13DBE2C0. Reading from address 0000000C.

Stack Trace:
---------------------------------------------------------------
13DBE2C0 (libtox 13DA0000): ..\toxcore\group.c (2245): do_groupchats
[/code]

[close]

Post Merge: 30 09 2015, 01:06:58+ Fresh Tox Crash when connection has fallen down into oblivion once upon a time...

http://trac.miranda-ng.org/ticket/1056

tox_core.cpp: CToxProto::UninitToxCore

Code: [Select]

Likely cause of the crash plugin: Tox protocol

Exception: Access Violation at address 1720FC28. Reading from address 00000004.

Stack Trace:
---------------------------------------------------------------
1720FC28 (Tox 17200000): e:\sources\miranda_ng_compilation\protocols\tox\src\tox_core.cpp (122): CToxProto::UninitToxCore
1720C3D2 (Tox 17200000): e:\sources\miranda_ng_compilation\protocols\tox\src\tox_network.cpp (157): CToxProto::PollingThread
1224C554 (mir_core 12240000): e:\sources\miranda_ng_compilation\src\mir_core\src\threads.cpp (154): forkthreadex_r
78AFC556 (MSVCR100 78AA0000): (filename not available) (0): endthreadex
78AFC600 (MSVCR100 78AA0000): (filename not available) (0): endthreadex
7C80B729 (kernel32 7C800000): (filename not available) (0): GetModuleFileNameA

[close]

[Corak]

+ Fresh Tox crash on "TCP_connection.c: find_tcp_connection_relay"

http://trac.miranda-ng.org/ticket/1057

"TCP_connection.c: find_tcp_connection_relay"

Code: [Select]

Exception: Access Violation at address 13DB3427. Reading from address 00000050.

Stack Trace:
---------------------------------------------------------------
13DB3427 (libtox 13DA0000): ..\toxcore\TCP_connection.c (405): find_tcp_connection_relay


[close]

[santa]

Miranda: latest nightly build.

After sending long message splitted into two parts from Miranda to qTox, reciever gets second part many times till Miranda restart.

Miranda tox protocol reconnection and qTox restart does not fix the problem.

[Vulpix]

@santa, I think this is some kind of weird interaction between Tabsrmm and tox/steam again. I've had this happen a few times, consulted with robyer, even showed him logs, but there was nothing conclusive.

In both cases miranda tries to resend the message LOTS of times. In fact there is an even scarier issue where miranda will send text from a different conversation to a different contact if you queue up a split message and then start chatting with someone else.

My recommendation is to disable long message splitting in tabsrmm. It doesn't work reliably.

[santa]

@Vulpix, thank you, I'll disable it.

There was another issue with Tox.

It crashed at Tox/src/tox_network.cpp:5 CToxProto::IsOnline(), where toxThread was not NULL, but it was points to deallocated memory.
Message was "Unhandled exception at 0x1720BCBA (Tox.dll) in Miranda32.exe: 0xC0000005: Access violation reading location 0x14F6FF00."

[Robyer]

I looked at Tox sources again, and CToxProto::SendMsg() and CToxProto::OnSendMessage() respectively is wrong. That may be very likely cause for the problems you're experiencing with the sending messages.

@unsane: in SendMsg() you should generate (increment internal) message number, start a new working thread with the parameters (hcontact, message, message number) and just return the message number immediatelly.
Then in the other thread you can really send message and make ProtoBroadcastAck to notify success or error for this message.
Miranda must get the number immediatelly so it can couple with the ProtoBroadcastAck calls later (where wParam is the message number).

e.g. in FB it's used just:

Code: [Select]

int FacebookProto::SendMsg(MCONTACT hContact, int, const char *msg)
{
std::string message = msg;
unsigned int msgId = InterlockedIncrement(&facy.msgid_);

ForkThread(&FacebookProto::SendMsgWorker, new send_direct(hContact, message, msgId));
return msgId;
}


EDIT: Same implementation is in SkypeWeb and Steam too.
Weird is, though, that all other protocols have it (IMHO) more or less wrong too. Which means either everyone else has it wrong, or I am partially wrong (or too strict) too. But my real experiments got me to my working solution.

One thing I don't understand is that why some protocols when notifying errors do it immediatelly and make it impossible to pair this error message with the message number they return later. I don't think communication windows can handle this properly (what if I send fast 5 messages almost at same time and then only some of them receive error? - maybe this is the one of errors that I was experiencing from time to time in some protocols, and I thought it's just miranda fault, not protocol)

EDIT2: I just tested it with Jabber and it's wrong. And since almost all other protocols have similar implementation, they will be all wrong in same way. My solution is correct, I recommend rewriting all protocols' SendMsg method to my mentioned implementation.

[unsane]

@unsane: in SendMsg() you should generate (increment internal) message number, start a new working thread with the parameters (hcontact, message, message number) and just return the message number immediatelly.

When Steam (or SkypeWeb, or FB) protocol sends a message it makes http request and wait the response. It can be fast or slow or very slow. So i have no any choice except to move it in another thread.

Tox just creates a packet with message and returns the unique message id. I suppose that it fast. Later, when message is received tox core calls OnReadReceipt in which i can to report about successful receipt. Why i should wrap it in thread and create one more unique number?

[Robyer]

1) Return value of SendMsg function is "message number" (which must be unique amongst all messages being sent at same time).
2) To properly call ProtoBroadcastAck with info "message was sent successfully" or "message sending failed" you need to have this "message number", because you give it to ProtoBroadcastAck as wParam parameter.
3) Before calling ProtoBroadcastAck you need to give Miranda the "message number", which means you need to return from the SendMsg function to return it to Miranda, which means you must do your work AFTER that - in other thread - so SendMsg can (and must) return before you call ProtoBroadcastAck

It doesn't matter how slow or fast is your sending, point is, that Miranda must get "message number" (by returning from SendMsg) BEFORE you do ProtoBroadcastAck.

So yes, solution is to wrap the "insides" in other thread, and in SendMsg just start this tread and return the generated "message number" (it pairs this SendMsg "request" with the proto ack later).

Is this more understandable now?

[unsane]

1) Tox core generate unique message id. It value i return from SendMsg. It value is
2) When message received i call ProtoBroadcastAck with unique message id.
3) I don't think that OnReadReceipt can be called before OnSendMessage ends execution.

It's not a solution it useless wrapper.

[Robyer]

unsane, you're talking about something else. I said nothing about OnReadReceipt(), it has nothing to do with it.

I'm talking about SendMsg() method only. (I mentioned also OnSendMessage() because you are just calling OnSendMessage() inside SendMsg(), but everything I said applies only for SendMsg() method).

EDIT: It's all about (tab)srmm's message queue - the SendMsg result. It has nothing to do with database.

[santa]

Additional information about CToxProto::IsOnline() crash.
It was after network connection lost and reconnection, when Tox tried to reconnect.

Miranda: latest nightly build.

Added: same problem at setting tox protocol offline.

[Robyer]

santa, Vulpix, unsane commited the change. Please try to enable the message splitting and report if it is working or not now.

santa, there is commit for your isOnline crash too.

[santa]

IsOnline crash is there yet. Sending Tox proto online and offline lead to crash with toxThread reference points to invalid memory.

Stack is

Spoiler

>  Tox.dll!CToxProto::IsOnline() Line 5   C++
    Tox.dll!CToxProto::SetAwayMsg(int __formal, const wchar_t * msg) Line 204   C++
    mir_app.mir!CallProtoServiceInt(unsigned int hContact, const char * szModule, const char * szService, unsigned int wParam, long lParam) Line 419   C++
    mir_app.mir!Proto_SetStatus(const char * szProto, unsigned int status) Line 249   C++
    mir_app.mir!StatusMenuExecService(unsigned int wParam, long __formal) Line 606   C++
    mir_core.mir!CallService(const char * name, unsigned int wParam, long lParam) Line 543   C++
    mir_app.mir!Menu_ProcessCommand(TMO_IntMenuItem * hMenuItem, long lParam) Line 455   C++

[close]

Cannot test message splitting for now, because my only Tox contact is offline