Closed
Bug 190177
Opened 22 years ago
Closed 16 years ago
ASSERTION: received wrong amount: 'received == writeCount', file .../xpcom/tests/TestPipes.cpp, line 273
Categories
(Core :: XPCOM, defect)
Core
XPCOM
Tracking
()
RESOLVED
FIXED
mozilla1.9.1b1
People
(Reporter: timeless, Assigned: sgautherie)
References
Details
(Keywords: assertion)
Attachments
(1 file, 1 obsolete file)
3.67 KB,
patch
|
shaver
:
review+
benjamin
:
superreview+
|
Details | Diff | Splinter Review |
SunOS DEATHSTARII 5.8 Generic_108528-17 sun4u sparc SUNW,Sun-Blade-100 Apps listed below live in ~/bin and have their libraries in ~/lib gmake: GNU Make 3.80 cvs: Concurrent Versions System (CVS) 1.11 (client/server) glib: 1.2.10 libIDL: 0.6.8 gtar: tar (GNU tar) 1.13.19 Not Installed: gtk, qt I'm starting to play with mozilla on solaris (again). The current configuration is xpcom standalone (I'll attach my mozconfig). Anyway $ ./run-mozilla.sh -g -d dbx ./TestPipes Type Manifest File: /export/home/timeless/mozilla/debug-xpcom-sparc-sun-solaris2.8/dist/bin/components/xpti.dat TestChainedPipes wrote total of 595886 bytes EOF count = 595886 read 595886 bytes, time = 4484ms Testing New Pipes: segment size 16 buffer size 16 Testing long writes... read 1222211 bytes, time = 12226ms wrote 1222211 bytes, time = 12226ms Testing short writes... ###!!! ASSERTION: received wrong amount: 'received == writeCount', file /export/home/timeless/mozilla/xpcom/test s/TestPipes.cpp, line 270 Break: at file /export/home/timeless/mozilla/xpcom/tests/TestPipes.cpp, line 270 Suspending process; attach with the debugger. Current function is TestShortWrites 270 NS_ASSERTION(received == writeCount, "received wrong amount"); (dbx) where current thread: t@1 [1] _kill(0x0, 0x17, 0xff35e000, 0x17, 0x656e6400, 0x53750000), at 0xff29f7cc [2] nsDebug::Break(0x17457, 0x10e, 0xff2bfc90, 0xff2bfc90, 0x17440, 0x17457), at 0xff1219f0 [3] nsDebug::Assertion(0x1742a, 0x17440, 0x17457, 0x10e, 0x3039, 0xffff8000), at 0xff121838 =>[4] TestShortWrites(in = 0x55bfc, out = 0x55c20), line 270 in "TestPipes.cpp" [5] RunTests(segSize = 16U, segCount = 1U), line 541 in "TestPipes.cpp" [6] main(argc = 1, argv = 0xffbefaac), line 645 in "TestPipes.cpp" (dbx) print received received = 16U (dbx) print writeCount writeCount = 17U The assert happens a *lot*.
Comment 2•22 years ago
|
||
probably fallout from my checkin for bug 176919. -> me
Assignee: dougt → darin
fwiw, while the specific instance here shows received/writecount off by one this isn't always the case.
Updated•19 years ago
|
Assignee: darin → nobody
QA Contact: scc → xpcom
Comment 4•17 years ago
|
||
I just hit this on Firefox 3 RC2, WinXP, running make check: TestPipes!RunTests+0x0000000000000160 (c:\gecko1_9\mozilla\xpcom\tests\testpipes.cpp, line 422) TestPipes!main+0x000000000000009B (c:\gecko1_9\mozilla\xpcom\tests\testpipes.cpp, line 524) TestPipes!__tmainCRTStartup+0x00000000000001A6 (f:\sp\vctools\crt_bld\self_x86\crt\src\crtexe.c, line 597) TestPipes!mainCRTStartup+0x000000000000000D (f:\sp\vctools\crt_bld\self_x86\crt\src\crtexe.c, line 414) kernel32!RegisterWaitForInputIdle+0x0000000000000049
Comment 6•16 years ago
|
||
Clarification - I hit this every single time I run make check. received is 16, writeCount is higher, usually equal to 19. Is this test still valid?
Comment 7•16 years ago
|
||
After further examination, I think I'm simply hitting a racing condition. The segment size is 16, and I notice in my debug output that just as the assertion failure hits, we're reading another few bytes at the same time. Also, by changing one line: http://hg.mozilla.org/mozilla-central/index.cgi/annotate/tip/xpcom/tests/TestPipes.cpp#l266 - if (gTrace) + if (PR_TRUE) The test passes.
Updated•16 years ago
|
OS: Solaris → All
Hardware: Sun → All
Comment 8•16 years ago
|
||
Happens consistently on Irix too, and the above one line patch doesn't seem to remedy the situation. In my case it's received==16, writeCount==17, on the third iteration of the loop.
Assignee | ||
Comment 9•16 years ago
|
||
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1a2pre) Gecko/2008073018 SeaMonkey/2.0a1pre] (home made) (W2Ksp4) {{ Testing short writes... ###!!! ASSERTION: received wrong amount: 'received == writeCount', file .../mozilla/xpcom/tests/TestPipes.cpp, line 273 => mFreeCount: 1154 -- LEAKED 242 !!! }} NB: I guess the leak is caused be interrupting the process, but reporting it just in case.
Summary: ASSERTION: received wrong amount: 'received == writeCount', file /export/home/timeless/mozilla/xpcom/tests/TestPipes.cpp, line 270 → ASSERTION: received wrong amount: 'received == writeCount', file .../xpcom/tests/TestPipes.cpp, line 273
Whiteboard: [This stops |make check|]
Assignee | ||
Comment 10•16 years ago
|
||
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1a2pre) Gecko/2008080202 SeaMonkey/2.0a1pre] (home, debug default) (W2Ksp4) Yes, there was some kind of "bad timing (/race)" condition between the functions (= threads). Typical example (but not the only one) would be: the writer sends 16 + 3, and registers 19, the reader reads 16, registers 16, reads 3, and |WaitForReceipt()| already returns with 16, thus the assertion. Core issue: *Actually wait for all the (sent) data to arrive, instead of "some" only. *NB: |NS_ASSERTION(mReceived >= 0, ...);| used to be useless, as it was always true :-< Unrelated: *Merge 3 |printf()| into 1. *Move a |buf[count] = '\0';| inside an |if|. *Remove a useless |nsAutoCMonitor mon(this);|.
Assignee: nobody → sgautherie.bz
Attachment #112326 -
Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #332052 -
Flags: review?(shaver)
Assignee | ||
Updated•16 years ago
|
Flags: in-testsuite-
Whiteboard: [This stops |make check|]
Target Milestone: --- → mozilla1.9.1a2
Assignee | ||
Updated•16 years ago
|
Attachment #332052 -
Flags: superreview?(benjamin)
Attachment #332052 -
Flags: review?(benjamin)
Updated•16 years ago
|
Attachment #332052 -
Flags: superreview?(benjamin)
Attachment #332052 -
Flags: superreview+
Attachment #332052 -
Flags: review?(benjamin)
![]() |
||
Comment 11•16 years ago
|
||
Ran into this today... for what it is worth the patch looks good and fixes this bug.
Comment 12•16 years ago
|
||
Comment on attachment 332052 [details] [diff] [review] (Av1) Fix broken logic ++ [Checkin: Comment 15] This patch also fixes "make check" on my windows debug build (for this test, at least).
![]() |
||
Comment 13•16 years ago
|
||
Brian, are there other tests failing with make check on debug builds? If so, could you file them and make bug 448802 depend on them?
Updated•16 years ago
|
Attachment #332052 -
Flags: review?(shaver) → review?(doug.turner)
Comment 14•16 years ago
|
||
Comment on attachment 332052 [details] [diff] [review] (Av1) Fix broken logic ++ [Checkin: Comment 15] r=shaver
Attachment #332052 -
Flags: review?(doug.turner) → review+
Assignee | ||
Updated•16 years ago
|
Keywords: checkin-needed
![]() |
||
Comment 15•16 years ago
|
||
Pushed to mozilla-central http://hg.mozilla.org/mozilla-central/index.cgi/rev/82033131d22fcfcf911a90a6bbdacb6b811df907
Assignee | ||
Updated•16 years ago
|
Attachment #332052 -
Attachment description: (Av1) Fix broken logic ++ → (Av1) Fix broken logic ++
[Checkin: Comment 15]
Assignee | ||
Updated•16 years ago
|
Target Milestone: mozilla1.9.1a2 → mozilla1.9.1
Assignee | ||
Updated•16 years ago
|
Target Milestone: mozilla1.9.1 → mozilla1.9.1b1
You need to log in
before you can comment on or make changes to this bug.
Description
•