Getting panic: (*serialize.BadMsgNotification) 0xc0000381c0 [recovered] on Auth example #49
Comments
|
Hey @TibebeJS! Could you please test your code on this branch? You can switch it in two ways, if you using go mod, add commit hash (@6582c6e), if not, you can just checkout branch manualy: If this wont help, ping me, i'll look more deep in this bug. |
|
sorry for the delay, I have given the @6582c6e version a try (with some modification on the code since some of the API's have been changed). But a similar issue still persists, my What could I be missing? |
|
Any Idea on what might be the underlying issue is, please? |
|
@TibebeJS sorry for long delay, i came back to you after holidays |
|
Hi, Same problem here for the "get_updates" example... &objects.BadMsgNotification{ |
|
This panic occurs whenever I download a large file (about 1 GiB). I'm curious what caused it. Any guesses? |
|
And it's always either mtproto.ErrBadMsgSeqNoTooLow or mtproto.ErrBadMsgSeqNoTooHigh. |
|
Craaaap i don't know how to fix it... Maybe we need to add additional mutex to tcp connection? |
|
Haven't done anything with go or heard of this package before the ping. It's going to be about impossible for me to provide any assistance. Telethon's handling of code 32/33 is a hack which really shouldn't be executed . 16 or 17 though you do need to fix your time offset and resend the corresponding message. Note that Telegram has a page explaining this. PM me on Telegram if you're developing stuff with MTProto and want to join an unofficial group of MTProto devs, maybe other peeps can help. |
|
Hey @quenbyako, any luck so far? I have a guess that this problem may be related to the request processing speed of the MTProto server. In fact, this problem rarely occurs if I put a rate limiting strategy (like 10 req/s) in my code. |
|
@aofei: I tried to copy messages handling from telethon (thanks Lonami for hint) but no progress at al... Someone whispered in my ear a small inside that you're not required to save seqno in session and can recreate connection starts with 1. I try this resolution on weekends and come back with response |
|
Good news, I fixed this bug by simply adding this var magicMu sync.Mutex
func (m *MTProto) sendPacketNew(request tl.Object, expectedTypes ...reflect.Type) (chan tl.Object, error) {
magicMu.Lock()
resp := make(chan tl.Object)
if m.serviceModeActivated {
resp = m.serviceChannel
}
var data []byte
var err error
var msgID = utils.GenerateMessageId()
msg, err := tl.Marshal(request)
if err != nil {
magicMu.Unlock()
return nil, errors.Wrap(err, "encoding request message")
}
if m.encrypted {
requireToAck := false
if MessageRequireToAck(request) {
m.mutex.Lock()
m.waitAck(msgID)
m.mutex.Unlock()
requireToAck = true
}
data, err = (&messages.Encrypted{
Msg: msg,
MsgID: msgID,
AuthKeyHash: m.authKeyHash,
}).Serialize(m, requireToAck)
if err != nil {
magicMu.Unlock()
return nil, errors.Wrap(err, "serializing message")
}
if !isNullableResponse(request) {
m.mutex.Lock()
m.responseChannels[msgID] = resp
if len(expectedTypes) > 0 {
m.expectedTypes[msgID] = expectedTypes
}
m.mutex.Unlock()
} else {
// ответов на TL_Ack, TL_Pong и пр. не требуется
go func() {
// горутина, т.к. мы ПРЯМО СЕЙЧАС из resp не читаем
resp <- &objects.Null{}
}()
}
// этот кусок не часть кодирования так что делаем при отправке
m.lastSeqNo += 2
} else {
data, _ = (&messages.Unencrypted{ //nolint: errcheck нешифрованое не отправляет ошибки
Msg: msg,
MsgID: msgID,
}).Serialize(m)
}
magicMu.Unlock()
//? https://core.telegram.org/mtproto/mtproto-transports#intermediate
size := make([]byte, 4)
binary.LittleEndian.PutUint32(size, uint32(len(data)))
_, err = m.conn.Write(size)
if err != nil {
return nil, errors.Wrap(err, "sending data")
}
//? https://core.telegram.org/mtproto/mtproto-transports#abridged
// _, err := m.conn.Write(utils.PacketLengthMTProtoCompatible(data))
// check(err)
_, err = m.conn.Write(data)
if err != nil {
return nil, errors.Wrap(err, "sending request")
}
return resp, nil
} |
|
Sounds like a data race; not sure how the library is organized but if there's concurrent access to the MTP state (like message ID or sequence number), that should indeed be behind a lock. |
|
@aofei oooow i got it! problem is that multiple requests getting seqno in parallel but it's illegal for telegram service. F.e.: Boom, it returns bad message. Fuck, i should notice this earlier, seqno mutex and request is single one instead twot different. |
|
@innovative-sol @TibebeJS @aofei looks like we fixed it. Try it out with the latest commit and give us a little feedback, please. Hope that for you it works as well as for me. |
|
Bad news, I still get this error in my tests. 😥 |
|
Perhaps we should ensure that |
|
It seems that the |
|
|
From logging inside sendPacket, I've found two issues that seem to be causing this together. Secondly, the error occurs after two messages with identical msgID happen - not seqNo misordering or thread safety as thought before. There are two potential fixes - one is to use the suggested method in that thread of storing a Start time and using time.Sub to get nano-second precision that way. This works and solves the issue, as duplicate IDs won't occur. However it would break potentially if any other function than sendPacket called this utility function - I'd suggest moving it into network.go if this fix is to be used, so it can be a private method. Unfortunately I'm not able to fully test this fix due to #86 blocking me from further testing - but I have gone from receiving the BadMsgNotification on almost all runs to never after implementing this change. Let me know if you'd like a PR of a suggested full fix. |
|
@MJDrgn Thanks, it seems to be working for me. |
|
@quenbyako I did, there may be some additions from @MJDrgn. |
|
@quenbyako panic: (*objects.BadMsgNotification) 0xc0001d4020 |
|
Auth. &objects.BadMsgNotification{ |
I'm getting the following error when I try to run the example auth code
What is the possible cause and how do I solve it?
The text was updated successfully, but these errors were encountered: