NaClBrowserTestPnacl.SysconfNprocessorsOnln not run with a blocking background thread |
|||
Issue descriptionVersion: R51 OS: ChromeOS What steps will reproduce the problem? (1) Run the browser test NaClBrowserTestPnacl.SysconfNprocessorsOnln with OS_CHROMEOS defined (2) The test blocks forever What is the expected output? The test passed What do you see instead? Timed out The bug is discovered when submitting https://codereview.chromium.org/1828533002/ . That CL creates a dedicated thread on background which blocks read /dev/kmsg. The test is blocked forever for unknown reason. Note that it only happens for release binary, but not debug binary. Disable the test on Chrome OS for now.
,
Mar 25 2016
,
Mar 25 2016
Your example code won't reliably repro the problem because of a race condition: the fflush(NULL) can happen before the child thread enters fgets(). If you do sleep(1) before fflush(NULL), you'll see that fflush(NULL) blocks.
,
Mar 25 2016
yes you're right.. I can reproduce it now. While not knowing why.
,
Mar 28 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/b238d39b1f0e3dd475a91f5ac04534a084e12282 commit b238d39b1f0e3dd475a91f5ac04534a084e12282 Author: cylee <cylee@chromium.org> Date: Mon Mar 28 06:33:54 2016 1. Enable UMA histogram logger for low memory kill events in ArcMetricsService. - Arc.LowMemoryKiller.Count: cumulative count of #kills. - Arc.LowMemoryKiller.FreedSize: Memory freed by each kill. - Arc.LowMemoryKiller.TimeDelta: Elapsed time since last kill. 2. renamed UMA histogram ArcRuntime.* => Arc.* 3. Move ArcLowMemoryMonitor to components/ for better DEPS management. BUG= 597899 TEST="Tested on minnie" Review URL: https://codereview.chromium.org/1828533002 Cr-Commit-Position: refs/heads/master@{#383482} [modify] https://crrev.com/b238d39b1f0e3dd475a91f5ac04534a084e12282/chrome/chrome_browser_chromeos.gypi [modify] https://crrev.com/b238d39b1f0e3dd475a91f5ac04534a084e12282/chrome/test/nacl/nacl_browsertest.cc [modify] https://crrev.com/b238d39b1f0e3dd475a91f5ac04534a084e12282/components/arc.gypi [modify] https://crrev.com/b238d39b1f0e3dd475a91f5ac04534a084e12282/components/arc/BUILD.gn [modify] https://crrev.com/b238d39b1f0e3dd475a91f5ac04534a084e12282/components/arc/DEPS [rename] https://crrev.com/b238d39b1f0e3dd475a91f5ac04534a084e12282/components/arc/metrics/arc_low_memory_killer_monitor.cc [rename] https://crrev.com/b238d39b1f0e3dd475a91f5ac04534a084e12282/components/arc/metrics/arc_low_memory_killer_monitor.h [modify] https://crrev.com/b238d39b1f0e3dd475a91f5ac04534a084e12282/components/arc/metrics/arc_metrics_service.cc [modify] https://crrev.com/b238d39b1f0e3dd475a91f5ac04534a084e12282/components/arc/metrics/arc_metrics_service.h [modify] https://crrev.com/b238d39b1f0e3dd475a91f5ac04534a084e12282/tools/metrics/histograms/histograms.xml
,
Mar 30 2016
|
|||
►
Sign in to add a comment |
|||
Comment 1 by cylee@google.com
, Mar 25 2016Turns out to be blocked at fflush(NULL)in nacl_browsertest.cc If changed to fflush(stderr) then the block goes away. I don't understand why so yet. A simple try to mimic the logic could NOT reproduce the problem. It may have something to do with chrome/unit test architecture (e.g., message loop, etc.) #include <stdio.h> #include <thread> void task() { char x[1000]; FILE* f = fopen("/dev/kmsg", "r"); fseek(f, 0, SEEK_END); printf("begin"); while(fgets(x, 1000, f)) { printf("%s", x); } } int main() { std::thread t1(task); t1.detach(); fprintf(stderr, "main thread\n"); fflush(NULL); fprintf(stderr, "after fflush\n"); pthread_exit(NULL); return 0; }