Closed Bug 341275 Opened 20 years ago Closed 13 years ago

[@ msvcrt!memcpy - nsStorageInputStream::Read]

Categories

(Core :: XPCOM, defect)

Product:
Core
Component:
XPCOM
Version:
1.8 Branch
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED INCOMPLETE

People

(Reporter: timeless, Unassigned)

References

(
URL
)

Details

(Keywords: crash)

Crash Data

first, this should not be marked as a duplicate of bug 207846. anyone doing that will risk losing their bugzilla privileges as it indicates that they have not read comment 0 :). Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.4) Gecko/20060504 Firefox/1.5.0.4 AllPeers Beta 0.34 ooh, talkback and windbg get along. Unfortunately, I think i'm going to censor this stack until I get permission from allpeers to post it. fwiw, all the frames are correct (I personally can see the function names for the 3 dll frames and they do make sense with the mozilla frames which in turn make sense w/ the windows frames). This is not exactly the talkback incident as it's listed in the database. Incident ID: 19788241 Stack Signature memcpy Product ID Firefox15 Build ID 2006050410 Trigger Time 2006-06-12 08:52:13.0 Platform Win32 Operating System Windows NT 5.1 build 2600 Module msvcrt.dll + (00036fa3) URL visited allpeers User Comments detailed stack is kinda available. i'll need to coordinate w/ dbaron Since Last Crash 291253 sec Total Uptime 1701352 sec Trigger Reason Access violation Source File, Line No. N/A Stack Trace msvcrt!memcpy+0x33 nsStorageInputStream::Read [c:/builds/tinderbox/Fx-Mozilla1.8.0/WINNT_5.2_Depend/mozilla/xpcom/io/nsStorageStream.cpp, line 443] nsStorageInputStream::Read [c:/builds/tinderbox/Fx-Mozilla1.8.0/WINNT_5.2_Depend/mozilla/xpcom/io/nsStorageStream.cpp, line 443] apDatabase.dll + 0x12491 (0x01b42491) apDatabase.dll + 0x9efc (0x01b39efc) apDatabase.dll + 0x94ba (0x01b394ba) PL_HandleEvent [c:/builds/tinderbox/Fx-Mozilla1.8.0/WINNT_5.2_Depend/mozilla/xpcom/threads/plevent.c, line 689] nsThread::Main [c:/builds/tinderbox/Fx-Mozilla1.8.0/WINNT_5.2_Depend/mozilla/xpcom/threads/nsThread.cpp, line 134] kernel32!BaseThreadStart+0x37 I'm not sure I can do much with it beyond this. It's possible to actually build your own msvcrt and then use that to get actual source lines for it, but that's a bit too much effort. Offhand, it looks like a memcpy(foo, 0, size) msvcrt!memcpy: 77c46f70 55 push ebp 77c46f71 8bec mov ebp,esp 77c46f73 57 push edi 77c46f74 56 push esi 77c46f75 8b750c mov esi,[ebp+0xc] 77c46f78 8b4d10 mov ecx,[ebp+0x10] 77c46f7b 8b7d08 mov edi,[ebp+0x8] 77c46f7e 8bc1 mov eax,ecx 77c46f80 8bd1 mov edx,ecx 77c46f82 03c6 add eax,esi 77c46f84 3bfe cmp edi,esi 77c46f86 7608 jbe msvcrt!memcpy+0x20 (77c46f90) 77c46f88 3bf8 cmp edi,eax 77c46f8a 0f8278010000 jb msvcrt!memcpy+0x198 (77c47108) 77c46f90 f7c703000000 test edi,0x3 77c46f96 7514 jnz msvcrt!memcpy+0x3c (77c46fac) 77c46f98 c1e902 shr ecx,0x2 77c46f9b 83e203 and edx,0x3 77c46f9e 83f908 cmp ecx,0x8 77c46fa1 7229 jb msvcrt!memcpy+0x5c (77c46fcc) 77c46fa3 f3a5 rep movsd ds:7f57a9f8=6168533c es:00000000=???????? 77c46fa5 ff2495b870c477 jmp dword ptr [msvcrt!memcpy+0x148 (77c470b8)+edx*4] 77c46fac 8bc7 mov eax,edi 77c46fae ba03000000 mov edx,0x3 77c46fb3 83e904 sub ecx,0x4 77c46fb6 720c jb msvcrt!memcpy+0x54 (77c46fc4) 77c46fb8 83e003 and eax,0x3 77c46fbb 03c8 add ecx,eax fwiw, windbg says: EXCEPTION_RECORD: ffffffff -- (.exr ffffffffffffffff) ExceptionAddress: 77c46fa3 (msvcrt!memcpy+0x00000033) ExceptionCode: c0000005 (Access violation) ExceptionFlags: 00000000 NumberParameters: 2 Parameter[0]: 00000001 Parameter[1]: 00000000 Attempt to write to address 00000000 DEFAULT_BUCKET_ID: NULL_DEREFERENCE eax=7f57b9f8 ebx=00112c36 ecx=00000400 edx=00000000 esi=7f57a9f8 edi=00000000 eip=77c46fa3 esp=0295fd04 ebp=0295fd0c iopl=0 nv up ei pl nz ac pe nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010212 I don't actually know who is at fault since I can only see the mozilla code. allpeers will have the console log, the complete stack trace and a cab with the dump, so it's possible for them to do further analysis at a later time if necessary. I'm fairly certain that mReadCursor is 0, but i'm not sure what that means.
maybe it's trying to read a closed stream like in that livehttpheaders bug?
nsStorageInputStream::Close is a no-op on branch. nsStorageStream::Close nulls out some stuff, and shrinks the mSegmentedBuffer... But then calling GetSegment() should still work, I would think. So no, I doubt this is a Close() issue... I do think that if segment allocation fails this code will definitely crash, however. Dunno how relevant that is.
I did manage to get a stack. As near as I can see, it's getting an implausibly large value when calling Available() on the stream. Assuming that the variable values in the dump are correct, then this might explain why Read() is crashing (not that this is correct behavior). I have no idea why Available() is returning such a strange value, however. For this I would need some sort of reproducible testcase.
Is the implausibly large value something like ((unsigned long)-1) ?
No, it's more like 10^6 decimal. This is strange because we only use binary storage for thumbnails, which are generally about 4K or so. Honestly our software is far younger than Mozilla so I suspect this is a problem with our code, but I can't be sure unless I can reproduce somehow.
Is this still an issue in Firefox 3.5? If it is not, we should set the resolution of the bug to WORKSFORME.
Crash Signature: [@ msvcrt!memcpy - nsStorageInputStream::Read]
(In reply to Tanner M. Young [:tmyoung] from comment #6) > Is this still an issue in Firefox 3.5? > > If it is not, we should set the resolution of the bug to WORKSFORME. Unclear. But it's been so long and no response, so => incomplete
Status: UNCONFIRMED → RESOLVED
Closed: 13 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.