Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CrashReporter: Null pointer in QNonContiguousByteDeviceIoDeviceImpl::readPointer #2984

Closed
jturcotte opened this issue Mar 18, 2015 · 0 comments
Labels

Comments

@jturcotte
Copy link
Member

This stack appears quite a few times in the few 1.8 crash reports that we already reported:

Crash reason:  EXCEPTION_ACCESS_VIOLATION_READ
Crash address: 0x0
Process uptime: 1597 seconds

Thread 0 (crashed)
 0  0x0
    eip = 0x00000000   esp = 0x0028d64c   ebp = 0x0939e7f0   ebx = 0x00000000
    esi = 0x00000000   edi = 0x08791e28   eax = 0x00000002   ecx = 0x06d0a320
    edx = 0x00000000   efl = 0x00010287
    Found by: given as instruction pointer in context
 1  Qt5Core.dll!QIODevice::read [qiodevice_p.h : 230 + 0x2]
    eip = 0x66a31419   esp = 0x0028d650   ebp = 0x0939e7f0
    Found by: stack scanning
 2  Qt5Core.dll!QNonContiguousByteDeviceIoDeviceImpl::readPointer [qnoncontiguousbytedevice.cpp : 325 + 0x1d]
    eip = 0x66a3590a   esp = 0x0028d6d0   ebp = 0x0028d738   ebx = 0x00000000
    esi = 0x099bc4e0   edi = 0x66d07888
    Found by: call frame info
 3  Qt5Network.dll!QNetworkReplyHttpImplPrivate::wantUploadDataSlot [qnetworkreplyhttpimpl.cpp : 1286 + 0x14]
    eip = 0x6d4494ad   esp = 0x0028d740   ebp = 0x0028d8f8   ebx = 0x098fa5f0
    esi = 0x099bc4e0   edi = 0x66d07888
    Found by: call frame info
 4  Qt5Network.dll!QNetworkReplyHttpImpl::qt_static_metacall [moc_qnetworkreplyhttpimpl_p.cpp : 238 + 0x1d]
    eip = 0x6d4d22c0   esp = 0x0028d780   ebp = 0x0028d8f8   ebx = 0x00000000
    esi = 0x099bc4e0   edi = 0x00000012
    Found by: call frame info
...
@jturcotte jturcotte added this to the 1.8.1 - Bugfix milestone Mar 18, 2015
@jturcotte jturcotte added the bug label Mar 18, 2015
jturcotte added a commit that referenced this issue Mar 23, 2015
This is largely a guess, but this is the only place where we use
a QIODevice to push data through QNAM and that the QIODevice isn't
a direct child of the QNetworkReply.

Fix the issue by making sure that we don't go back to the event loop
and possibly handle network events between the destruction of the
upload QIODevice and the QNetworkReply, which might lead to QNAM
dereferencing a dangling QIODevice pointer.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant