[chromium-dev] networking code in src/third_party/WebKit/WebCore/platform/network/mac
Hi, Can you please tell me if chromium on Mac OS X uses the networking code in src/third_party/WebKit/WebCore/platform/network/mac? Or the code there is for Webkit? I asked because chromium has this 'sandbox' architecture, so I am not sure if chromium's networking code is totally different (chromium specified) because of this difference in architecture. Thank you. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: networking code in src/third_party/WebKit/WebCore/platform/network/mac
I'm 99% sure we use what's in third_party On Mon, Oct 5, 2009 at 11:06 PM, hap 497 hap...@gmail.com wrote: Hi, Can you please tell me if chromium on Mac OS X uses the networking code in src/third_party/WebKit/WebCore/platform/network/mac? Or the code there is for Webkit? I asked because chromium has this 'sandbox' architecture, so I am not sure if chromium's networking code is totally different (chromium specified) because of this difference in architecture. Thank you. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: networking code in src/third_party/WebKit/WebCore/platform/network/mac
Our networking code lives under /trunk/src/nethttp://src.chromium.org/viewvc/chrome/trunk/src/net/ We use the code in WebCore/platform/network/chromium, even on Mac OS X. http://src.chromium.org/viewvc/chrome/trunk/src/net/-Darin On Mon, Oct 5, 2009 at 11:06 PM, hap 497 hap...@gmail.com wrote: Hi, Can you please tell me if chromium on Mac OS X uses the networking code in src/third_party/WebKit/WebCore/platform/network/mac? Or the code there is for Webkit? I asked because chromium has this 'sandbox' architecture, so I am not sure if chromium's networking code is totally different (chromium specified) because of this difference in architecture. Thank you. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Unkown Error During Building Chromium for Linux
It looks as though you didn't save stderr, only stdout, so the logs do not contain any actual error messages. 2009/10/5 Ujjwol (उज्जवल लामिछाने) ujjwollamichh...@gmail.com: While building chromium in Fedora 10, a strange build error has been encountered. The tail of the log of build(hammer --verbose) process is: [ujj...@ujjwol Desktop]$ tail VerboseChromeBuild.txt Copying /home/Ujjwol/chromium/home/chrome-svn/tarball/chromium/src/ sconsbuild/Debug/obj/chrome/_chrome_intermediate/repack/zh-CN.pak to / home/Ujjwol/chromium/home/chrome-svn/tarball/chromium/src/sconsbuild/ Debug/locales/zh-CN.pak ... Copying /home/Ujjwol/chromium/home/chrome-svn/tarball/chromium/src/ sconsbuild/Debug/obj/chrome/_chrome_intermediate/repack/zh-TW.pak to / home/Ujjwol/chromium/home/chrome-svn/tarball/chromium/src/sconsbuild/ Debug/locales/zh-TW.pak ... Copying /home/Ujjwol/chromium/home/chrome-svn/tarball/chromium/src/ sconsbuild/Debug/obj/chrome/_chrome_intermediate/repack/default.pak to /home/Ujjwol/chromium/home/chrome-svn/tarball/chromium/src/ sconsbuild/Debug/themes/default.pak ... g++ -o /home/Ujjwol/chromium/home/chrome-svn/tarball/chromium/src/ sconsbuild/Debug/obj/chrome/page_cycler_tests/test/page_cycler/ page_cycler_test.o -c -fno-rtti -fno-threadsafe-statics -Werror - pthread -fno-exceptions -Wall -D_FILE_OFFSET_BITS=64 -m32 -march=geode -pthread -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/ include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/ include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/pixman-1 - I/usr/include/freetype2 -I/usr/include/libpng12 -O0 -g - D__STDC_FORMAT_MACROS -DCHROMIUM_BUILD -DUNIT_TEST -DGTEST_HAS_RTTI=0 - D_DEBUG -I/home/Ujjwol/chromium/home/chrome-svn/tarball/chromium/src/ sconsbuild/Debug/obj/_global_intermediate/chrome -I/home/Ujjwol/ chromium/home/chrome-svn/tarball/chromium/src -I/home/Ujjwol/chromium/ home/chrome-svn/tarball/chromium/src/skia/config -I/home/Ujjwol/ chromium/home/chrome-svn/tarball/chromium/src/third_party/skia/include/ core -I/home/Ujjwol/chromium/home/chrome-svn/tarball/chromium/src/ third_party/skia/include/effects -I/home/Ujjwol/chromium/home/chrome- svn/tarball/chromium/src/skia/ext -I/home/Ujjwol/chromium/home/chrome- svn/tarball/chromium/src/third_party/harfbuzz/src -I/home/Ujjwol/ chromium/home/chrome-svn/tarball/chromium/src/third_party/harfbuzz/ contrib -I/home/Ujjwol/chromium/home/chrome-svn/tarball/chromium/src/ testing/gtest/include /home/Ujjwol/chromium/home/chrome-svn/tarball/ chromium/src/chrome/test/page_cycler/page_cycler_test.cc g++ -o /home/Ujjwol/chromium/home/chrome-svn/tarball/chromium/src/ sconsbuild/Debug/obj/test_shell/npapi_layout_test_plugin/__/ npapi_layout_test_plugin/PluginObject.os -c -fno-rtti -fno-threadsafe- statics -Werror -pthread -fno-exceptions -Wall -D_FILE_OFFSET_BITS=64 - m32 -march=geode -O0 -g -fPIC -D__STDC_FORMAT_MACROS -DCHROMIUM_BUILD - DENABLE_CHANNEL_MESSAGING=1 -DENABLE_DATABASE=1 -DENABLE_DATAGRID=0 - DENABLE_OFFLINE_WEB_APPLICATIONS=1 -DENABLE_DASHBOARD_SUPPORT=0 - DENABLE_DOM_STORAGE=1 -DENABLE_JAVASCRIPT_DEBUGGER=0 - DENABLE_JSC_MULTIPLE_THREADS=0 -DENABLE_ICONDATABASE=0 - DENABLE_NOTIFICATIONS=0 -DENABLE_XSLT=1 -DENABLE_XPATH=1 - DENABLE_SHARED_WORKERS=0 -DENABLE_SVG=1 -DENABLE_SVG_ANIMATION=1 - DENABLE_SVG_AS_IMAGE=1 -DENABLE_SVG_USE=1 - DENABLE_SVG_FOREIGN_OBJECT=1 -DENABLE_SVG_FONTS=1 -DENABLE_VIDEO=1 - DENABLE_WORKERS=1 -DBUILDING_CHROMIUM__=1 -DUSE_SYSTEM_MALLOC=1 - DWTF_USE_PTHREADS=1 -DU_STATIC_IMPLEMENTATION -D_DEBUG -I/home/Ujjwol/ chromium/home/chrome-svn/tarball/chromium/src/third_party/icu/public/ common -I/home/Ujjwol/chromium/home/chrome-svn/tarball/chromium/src/ third_party/icu/public/i18n -I/home/Ujjwol/chromium/home/chrome-svn/ tarball/chromium/src -I/home/Ujjwol/chromium/home/chrome-svn/tarball/ chromium/src/third_party/npapi -I/home/Ujjwol/chromium/home/chrome-svn/ tarball/chromium/src/third_party/npapi/bindings -I/home/Ujjwol/ chromium/home/chrome-svn/tarball/chromium/src/third_party/WebKit/ JavaScriptCore -I/home/Ujjwol/chromium/home/chrome-svn/tarball/ chromium/src/third_party/WebKit/JavaScriptCore/wtf /home/Ujjwol/ chromium/home/chrome-svn/tarball/chromium/src/webkit/tools/ npapi_layout_test_plugin/PluginObject.cpp g++ -o /home/Ujjwol/chromium/home/chrome-svn/tarball/chromium/src/ sconsbuild/Debug/obj/test_shell/npapi_layout_test_plugin/__/ npapi_layout_test_plugin/TestObject.os -c -fno-rtti -fno-threadsafe- statics -Werror -pthread -fno-exceptions -Wall -D_FILE_OFFSET_BITS=64 - m32 -march=geode -O0 -g -fPIC -D__STDC_FORMAT_MACROS -DCHROMIUM_BUILD - DENABLE_CHANNEL_MESSAGING=1 -DENABLE_DATABASE=1 -DENABLE_DATAGRID=0 - DENABLE_OFFLINE_WEB_APPLICATIONS=1 -DENABLE_DASHBOARD_SUPPORT=0 - DENABLE_DOM_STORAGE=1 -DENABLE_JAVASCRIPT_DEBUGGER=0 - DENABLE_JSC_MULTIPLE_THREADS=0 -DENABLE_ICONDATABASE=0 - DENABLE_NOTIFICATIONS=0 -DENABLE_XSLT=1
[chromium-dev] Re: Unkown Error During Building Chromium for Linux
Ok the new build log with stderr logged --- [?1034hscons: Reading SConscript files ... scons: done reading SConscript files. scons: Building targets ... Extracting last change to /home/Ujjwol/chromium/home/chrome-svn/ tarball/chromium/src/sconsbuild/Debug/obj/_global_intermediate/build/ LASTCHANGE Compiling /home/Ujjwol/chromium/home/chrome-svn/tarball/chromium/src/ sconsbuild/Debug/obj/test_shell/npapi_test_plugin/__/__/glue/plugins/ test/npapi_constants.os Compiling /home/Ujjwol/chromium/home/chrome-svn/tarball/chromium/src/ sconsbuild/Debug/obj/test_shell/npapi_test_plugin/__/__/glue/plugins/ test/npapi_test.os Linking /home/Ujjwol/chromium/home/chrome-svn/tarball/chromium/src/ sconsbuild/Debug/page_cycler_tests Linking /home/Ujjwol/chromium/home/chrome-svn/tarball/chromium/src/ sconsbuild/Debug/chrome Compiling /home/Ujjwol/chromium/home/chrome-svn/tarball/chromium/src/ sconsbuild/Debug/obj/test_shell/npapi_test_plugin/__/__/glue/plugins/ test/plugin_arguments_test.os Compiling /home/Ujjwol/chromium/home/chrome-svn/tarball/chromium/src/ sconsbuild/Debug/obj/test_shell/npapi_test_plugin/__/__/glue/plugins/ test/plugin_client.os Compiling /home/Ujjwol/chromium/home/chrome-svn/tarball/chromium/src/ sconsbuild/Debug/obj/test_shell/npapi_test_plugin/__/__/glue/plugins/ test/plugin_delete_plugin_in_stream_test.os Compiling /home/Ujjwol/chromium/home/chrome-svn/tarball/chromium/src/ sconsbuild/Debug/obj/test_shell/npapi_test_plugin/__/__/glue/plugins/ test/plugin_get_javascript_url_test.os Compiling /home/Ujjwol/chromium/home/chrome-svn/tarball/chromium/src/ sconsbuild/Debug/obj/test_shell/npapi_test_plugin/__/__/glue/plugins/ test/plugin_geturl_test.os Compiling /home/Ujjwol/chromium/home/chrome-svn/tarball/chromium/src/ sconsbuild/Debug/obj/test_shell/npapi_test_plugin/__/__/glue/plugins/ test/plugin_javascript_open_popup.os Compiling /home/Ujjwol/chromium/home/chrome-svn/tarball/chromium/src/ sconsbuild/Debug/obj/test_shell/npapi_test_plugin/__/__/glue/plugins/ test/plugin_new_fails_test.os Compiling /home/Ujjwol/chromium/home/chrome-svn/tarball/chromium/src/ sconsbuild/Debug/obj/test_shell/npapi_test_plugin/__/__/glue/plugins/ test/plugin_npobject_proxy_test.os Compiling /home/Ujjwol/chromium/home/chrome-svn/tarball/chromium/src/ sconsbuild/Debug/obj/test_shell/npapi_test_plugin/__/__/glue/plugins/ test/plugin_private_test.os Compiling /home/Ujjwol/chromium/home/chrome-svn/tarball/chromium/src/ sconsbuild/Debug/obj/test_shell/npapi_test_plugin/__/__/glue/plugins/ test/plugin_test.os Building loadable module /home/Ujjwol/chromium/home/chrome-svn/tarball/ chromium/src/sconsbuild/Debug/libnpapi_test_plugin.so collect2: ld returned 1 exit status scons: *** [/home/Ujjwol/chromium/home/chrome-svn/tarball/chromium/src/ sconsbuild/Debug/page_cycler_tests] Error 1 collect2: ld returned 1 exit status scons: *** [/home/Ujjwol/chromium/home/chrome-svn/tarball/chromium/src/ sconsbuild/Debug/chrome] Error 1 scons: building terminated because of errors. - On Oct 6, 12:17 pm, Lei Zhang thes...@chromium.org wrote: It looks as though you didn't save stderr, only stdout, so the logs do not contain any actual error messages. 2009/10/5 Ujjwol (उज्जवल लामिछाने) ujjwollamichh...@gmail.com: While building chromium in Fedora 10, a strange build error has been encountered. The tail of the log of build(hammer --verbose) process is: [ujj...@ujjwol Desktop]$ tail VerboseChromeBuild.txt Copying /home/Ujjwol/chromium/home/chrome-svn/tarball/chromium/src/ sconsbuild/Debug/obj/chrome/_chrome_intermediate/repack/zh-CN.pak to / home/Ujjwol/chromium/home/chrome-svn/tarball/chromium/src/sconsbuild/ Debug/locales/zh-CN.pak ... Copying /home/Ujjwol/chromium/home/chrome-svn/tarball/chromium/src/ sconsbuild/Debug/obj/chrome/_chrome_intermediate/repack/zh-TW.pak to / home/Ujjwol/chromium/home/chrome-svn/tarball/chromium/src/sconsbuild/ Debug/locales/zh-TW.pak ... Copying /home/Ujjwol/chromium/home/chrome-svn/tarball/chromium/src/ sconsbuild/Debug/obj/chrome/_chrome_intermediate/repack/default.pak to /home/Ujjwol/chromium/home/chrome-svn/tarball/chromium/src/ sconsbuild/Debug/themes/default.pak ... g++ -o /home/Ujjwol/chromium/home/chrome-svn/tarball/chromium/src/ sconsbuild/Debug/obj/chrome/page_cycler_tests/test/page_cycler/ page_cycler_test.o -c -fno-rtti -fno-threadsafe-statics -Werror - pthread -fno-exceptions -Wall -D_FILE_OFFSET_BITS=64 -m32 -march=geode -pthread -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/ include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/ include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/pixman-1 - I/usr/include/freetype2 -I/usr/include/libpng12 -O0 -g - D__STDC_FORMAT_MACROS -DCHROMIUM_BUILD -DUNIT_TEST -DGTEST_HAS_RTTI=0 - D_DEBUG -I/home/Ujjwol/chromium/home/chrome-svn/tarball/chromium/src/
[chromium-dev] Re: Unkown Error During Building Chromium for Linux
There not thing as out-of-memory for the ld process in dmesg. Here is the dmseg output: -- Initializing cgroup subsys cpuset Initializing cgroup subsys cpu Linux version 2.6.27.30-170.2.82.fc10.i686 (mockbu...@xenbuilder4.fedora.phx.redhat.com) (gcc version 4.3.2 20081105 (Red Hat 4.3.2-7) (GCC) ) #1 SMP Mon Aug 17 08:38:59 EDT 2009 BIOS-provided physical RAM map: BIOS-e820: - 0009f000 (usable) BIOS-e820: 0009f000 - 000a (reserved) BIOS-e820: 0010 - 7f66d800 (usable) BIOS-e820: 7f66d800 - 8000 (reserved) BIOS-e820: f800 - fc00 (reserved) BIOS-e820: fec0 - fec1 (reserved) BIOS-e820: fed18000 - fed1c000 (reserved) BIOS-e820: fed2 - fed9 (reserved) BIOS-e820: feda - feda6000 (reserved) BIOS-e820: fee0 - fee1 (reserved) BIOS-e820: fff0 - 0001 (reserved) DMI 2.4 present. last_pfn = 0x7f66d max_arch_pfn = 0x10 x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106 kernel direct mapping tables up to 3800 @ 7000-c000 Using x86 segment limits to approximate NX protection RAMDISK: 37ce3000 - 37fef0fd ACPI: RSDP 000FBBF0, 0024 (r2 DELL ) ACPI: XSDT 7F66F200, 005C (r1 DELLM08 27D80C13 ASL61) ACPI: FACP 7F66F09C, 00F4 (r4 DELLM08 27D80C13 ASL61) ACPI: DSDT 7F66F800, 5676 (r2 INT430 SYSFexxx 1001 INTL 20050624) ACPI: FACS 7F67E000, 0040 ACPI: HPET 7F66F300, 0038 (r1 DELLM081 ASL61) ACPI: APIC 7F66F400, 0068 (r1 DELLM08 27D80C13 ASL47) ACPI: MCFG 7F66F3C0, 003E (r16 DELLM08 27D80C13 ASL61) ACPI: SLIC 7F66F49C, 0176 (r1 DELLM08 27D80C13 ASL61) ACPI: BOOT 7F66EFC0, 0028 (r1 DELLM08 27D80C13 ASL61) ACPI: SSDT 7F66DA40, 04CC (r1 PmRefCpuPm 3000 INTL 20050624) 1142MB HIGHMEM available. 896MB LOWMEM available. mapped low ram: 0 - 3800 low ram: - 3800 bootmap 8000 - f000 (9 early reservations) == bootmem [00 - 003800] #0 [00 - 001000] BIOS data page == [00 - 001000] #1 [001000 - 002000]EX TRAMPOLINE == [001000 - 002000] #2 [006000 - 007000] TRAMPOLINE == [006000 - 007000] #3 [40 - 97712c]TEXT DATA BSS == [40 - 97712c] #4 [0037ce3000 - 0037fef0fd] RAMDISK == [0037ce3000 - 0037fef0fd] #5 [978000 - 97c000]INIT_PG_TABLE == [978000 - 97c000] #6 [09f000 - 10]BIOS reserved == [09f000 - 10] #7 [007000 - 008000] PGTABLE == [007000 - 008000] #8 [008000 - 00f000] BOOTMAP == [008000 - 00f000] Zone PFN ranges: DMA 0x - 0x1000 Normal 0x1000 - 0x00038000 HighMem 0x00038000 - 0x0007f66d Movable zone start PFN for each node early_node_map[2] active PFN ranges 0: 0x - 0x009f 0: 0x0100 - 0x0007f66d On node 0 totalpages: 521740 free_area_init_node: node 0, pgdat c07f7b00, node_mem_map c100 DMA zone: 3967 pages, LIFO batch:0 Normal zone: 223520 pages, LIFO batch:31 HighMem zone: 290176 pages, LIFO batch:31 Using APIC driver default ACPI: PM-Timer IO Port: 0x1008 ACPI: Local APIC address 0xfee0 ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled) ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 2, version 32, address 0xfec0, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) ACPI: IRQ0 used by override. ACPI: IRQ2 used by override. ACPI: IRQ9 used by override. Enabling APIC mode: Flat. Using 1 I/O APICs ACPI: HPET id: 0x8086a201 base: 0xfed0 Using ACPI (MADT) for SMP configuration information SMP: Allowing 2 CPUs, 0 hotplug CPUs mapped APIC to b000 (fee0) mapped IOAPIC to a000 (fec0) PM: Registered nosave memory: 0009f000 - 000a PM: Registered nosave memory: 000a - 0010 Allocating PCI resources starting at 8800 (gap: 8000:7800) PERCPU: Allocating 41372 bytes of per cpu data NR_CPUS: 32, nr_cpu_ids: 2, nr_node_ids 1 Built 1 zonelists in Zone order, mobility grouping on. Total pages: 517663 Kernel command line: ro root=UUID=cee72a65-1f1c-4750-b9c3-45662155075c rhgb quiet Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Initializing CPU#0 CPU 0 irqstacks, hard=c08a4000 soft=c0884000 PID hash table entries: 4096 (order: 12, 16384 bytes) Extended CMOS year: 2000 TSC: PIT calibration confirmed by PMTIMER. TSC: using PIT calibration value
[chromium-dev] buildbot failure in Chromium on Webkit Mac10.5, revision 28101
Automatically closing tree for test_shell_tests on Webkit Mac10.5 http://build.chromium.org/buildbot/waterfall/builders/Webkit%20Mac10.5/builds/4548 http://build.chromium.org/buildbot/waterfall/waterfall?builder=Webkit%20Mac10.5 --= Automatically closing tree for test_shell_tests on Webkit Mac10.5 =-- Revision: 28101 Blame list: y...@chromium.org Buildbot waterfall: http://build.chromium.org/ --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Unkown Error During Building Chromium for Linux
What linker are you using? Have you tried installing and using gold? Which targets fail? Can you at least build base and base_unittests? Also, next time you save a log, be sure to save *both* stdout and stderr, e.g. make foo log 21 --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Developer Tools will be busted in the next Dev Channel Chromium on Linux (my fault), can we work around it?
Hi guys, I'm sorry, but due to my lack of experience with Gyp files, the 221.7 version cut at 28100 will have disfunctional Developer tools. I fixed the problem in 28102 (a three lines fix to gyp file.) Can we somehow patch these changes (or maybe manually add devtools.html into Linux distribution) to avoid having busted DevTools for a week? --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Question about linux pixel tests
Not sure if this answers the question or not, but recall that linux falls back to the windows expectations when there isn't a linux-specific override. That could explain why it's not there. On Tue, Oct 6, 2009 at 1:03 AM, Drew Wilson atwil...@chromium.org wrote: Are some pixel tests currently disabled on the linux release buildbots? I'm trying to rebaseline some tests that are currently marked as FAIL in test_expectations, but I can't grab linux images because the .png files don't exist in the archive grabbed by the rebaseline tool. As an example, I'm looking at http://build.chromium.org/buildbot/layout_test_results/webkit-rel-linux/28080/layout-test-results.zip and trying to find fast/css/last-of-type-pseudoclass-expected.png (it's not in there). -atw -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Google Blogoscoped author tries out Chrome app shortcuts
Very glad to see someone looking at the issues! - *Sort of crucial:* Chrome won’t accept my system font definition, Fixedsys, I don't understand the problem description well enough to take action here. To explain, my CSS includes font-family: fixedsys, consolas, monospace; ... and Chrome doesn't use Fixedsys, but jumps to Consolas instead. Firefox finds Fixedsys fine. Apparently it being a system font confuses Chrome? (I also can't locate the font when trying to adjust my Chrome monospace default font in the options.) He just needs to learn how to create an application shortcut. Copy a chrome shortcut on the desktop, rename it, right click on it, properties, edit the command line to add the arguments wanted. I can't get this set up properly -- did you try it, could you please guide me through the steps? When I use a shortcut, then setting up a file extension association and then opening the associated file will make Vista route to the main program (Chrome, not Chrome App). Dragging the source file over the shortcut shows somewhat better behavior, but I didn't fully explore that route as it wouldn't be a solution in the first place (as I just want to double click my text files to edit). My goal is: - On Windows (Vista), open all file types of extension .foo with Chrome App, and pass the foo path to the application as anchor, like in http://netpadd/#C:\bar.foo Current workaround: using a CMD file with the following does the job, and I can properly connect .foo files with it (with the remaining issue that the batch window is briefly visible on startup): start C:\...\AppData\Local\Google\Chrome\Application\chrome.exe -- app=http://netpadd/#%1; cheers Philipp --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] chrome extension preferences
Hi all How can i set some preferences for my custom toolstrip extension ? I have the gmail sample extension and id like to add the ability to check a google apps account which involves hardcoding somewhere the specified domain. (differents logins/feeds urls) Thank you ;) --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Learning Webkit: High Level Webkit overview?
There is a document called How Chromium Displays Web Pages (http:// dev.chromium.org/developers/design-documents/displaying-a-web-page-in- chrome), however I haven't found an equivalent page for Webkit. E.g. How Webkit Renders Web Pages. The Chromium document doesn't go into the Webkit part. There is an old blog http://webkit.org/blog/114/webcore-rendering-i-the-basics/. Which talks about some of the render process but it seems to focus on CSS handling. I'm trying to diagram this process. E.g. We're load a simple web page with some body text, a couple divs; one with an image tag, one with a plugin like flash. What is happening from start to finish? I imagine the process like such: Content = HTML Parsing = DOM Construction = Layout (Render Tree Construction) = Rendering What is the first thing that is done? Which class is initially hit when a new web page request arrives? Which classes are responsible for parsing HTML/DOM/CSS? How is the plugin loaded? How is the image loaded? While these are questions that could be answered by studying the code in depth, it would be nice if there was such a basic introduction to Webkit rendering. Ideally one with nice pictures (like the Chromium docs), interaction diagrams and such. Perhaps this thread could become a source of knowledge for new comers. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [DESIGN DOC] registerProtocolHandler HTML5 API
That seems like a good plan. Has anyone ever tried formalizing it and floating it around to other vendors? I figured I should jump into the thread since I can provide some perspective on the UI from another vendor. I'm a principal designer on Firefox and this is a feature that I'm really passionate about. The UA would expose some way to activate all of this functionality for a site in one shot... I totally agree that users should be able to give Web apps additional privileges in one shot, as opposed to having to give them permission to do things like use offline storage, register to handle local files, and produce notifications individually (although we will likely allow users to revoke specific permissions). then a menu item in the browser might activate that the user could use to activate it. We are considering a menu item as well, however we haven't determined the best way to describe the action. I'm concerned that the term install has connotations that the Web app will actually be served locally (like how Zimbra desktop deploys with Mozilla's Prism), and a lot of users may have difficulty wrapping their head around what it literally means to install a Web app. We are also looking into granting these additional app privileges implicitly through actions that the user takes, like dragging a tab into the OS X dock or Windows quick launch bar. Additionally in Firefox 4 if the user drags a tab to the left our new Home Tab they will be able to create a small persistent tab (called an app tab) that will be automatically granted these additional privileges. A third option that I've been thinking about is adding a new item to the Windows start menu and OS X applications folder named Add Web Application. I think this works reasonably well conceptually since the app being created will ultimately be accessible next to the rest of the user's desktop applications. However, presenting UI outside of the browser is a little more aggressive than Firefox usually behaves. While UA interfaces are of course well outside of the scope of the standardization process for APIs, I think the Web as a whole would benefit if we coordinated to present a somewhat similar interface for this feature, at least in terms of terminology, any symbols used, etc. -Alex Faaborg On Oct 2, 4:23 pm, Jeremy Orlow jor...@chromium.org wrote: That seems like a good plan. Has anyone ever tried formalizing it and floating it around to other vendors? On Fri, Oct 2, 2009 at 4:11 PM, Ben Goodger (Google) b...@chromium.orgwrote: This relates somewhat to how we'd like people to install web applications. For that we figured a site would publish a manifest in some format (there was some talk about something like the extensions manifest) that specifies all kinds of appy things a site can do, like large icons, protocol schemes and mime types it can handle and the URLs for each, etc etc. The UA would expose some way to activate all of this functionality for a site in one shot... e.g. if the site published the data via some kind of link tag then a menu item in the browser might activate that the user could use to activate it. -Ben On Fri, Oct 2, 2009 at 2:55 PM, Jeremy Orlow jor...@chromium.org wrote: On Fri, Oct 2, 2009 at 2:48 PM, Peter Kasting pkast...@google.com wrote: On Fri, Oct 2, 2009 at 2:47 PM, Jeremy Orlow jor...@chromium.org wrote: Is this API even part of any standard? Maybe we should bring this up on WhatWG? The thread title is a clue that these are specced in HTML5 :) Not really. People abuse the term HTML5. Good example: WebSockets, WebDatabase, LocalStorage, Workers, and many of the other APIs we associate with HTML5 are not in that spec. Anyhow, apparently this was discussed very recently and I somehow missed the discussion: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/02 ... I'll try to take a look at the thread some time soon. Ben and/ or other UI guys, maybe you should too. Now is the time to make noise if we think this is a bad API. J --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Google Blogoscoped author tries out Chrome app shortcuts
(Duh, this groups is moderated, which explains why the post didn't show. Why doesn't Google Groups tell me my post is awaiting moderation after I post?) --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Google Blogoscoped author tries out Chrome app shortcuts
Not sure if my last reply was a success (Google Groups told me posting was successful but I can't see the post here yet after some minutes), so let me double post :) In a nutshell, I'm glad to see the issues being looked at! The Fixedsys font problem is this: In my CSS, I have the line font-family: fixedsys, consolas, monospace; but Chrome ignores the first font, and jumps to Consolas (Firefox finds Fixedsys fine). It being a system font might be part of the issue, I can also not locate Fixedsys in Chrome's monospace font options dialog. He just needs to learn how to create an application shortcut. Copy a chrome shortcut on the desktop, rename it, right click on it, properties, edit the command line to add the arguments wanted. Could you please guide me through the steps, did you try associating files? Just a basic edited shortcut doesn't do the job for me, as Windows (Vista) will set up the file association -- which I need to open files system wide with double click -- with the source exe when picking the shortcut... i.e. with basic Chrome, not Chrome App (dragging the file over the shortcut behaves somewhat better, but I didn't further explore this route as it's not a solution). To clarify, my goal is: - set up Windows (Vista) so that all .foo files (like myfile.foo) will automatically be opened with Chrome App at the location http://example/#path-to-foo-file (e.g. http://example/#C:\somefolder\myfile.foo). My current suboptimal workaround as mentioned is associating my files with a CMD file which reads: C:\Users\...\Chrome\Application\chrome.exe --app=http://example/#%1; cheers Philipp --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [DESIGN DOC] registerProtocolHandler HTML5 API
That seems like a good plan. Has anyone ever tried formalizing it and floating it around to other vendors? I figured I should jump into the thread since I can give some perspective on the UI from another vendor. I'm a principal designer on Firefox, and this is a feature that I'm really passionate about. The UA would expose some way to activate all of this functionality for a site in one shot... e.g. if the site published the data via some kind of link tag then a menu item in the browser might activate that the user could use to activate it. I completely agree with the user being able to give the Web app various privileges in one shot, as opposed to having to provide permissions individually, like access to a certain amount of offline storage, local file type registration, ability to produce notifications, etc (although we will likely allow users to revoke permissions to Web apps individually). I'm concerned that the notion of installing a Web app is going to be difficult for a lot of people to wrap their head around. This somewhat implies that the Web app is going to served locally (like how Zimbra Desktop currently deploys with Mozilla's Prism). So in terms of the Firefox UI, we haven't decided on the best way to describe the action of giving a Web app additional desktop-like privileges. While we will likely have an explicit menu item, we are also considering granting these privileges implicitly when the user takes an action like dragging a tab into their OS X Dock, or Windows quick launch bar. We also may grant the Web app certain privileges in Firefox 4 when it is dragged to the left of the home tab, and now exists in a persistent state that we are referring to as an app tab. I've also been considering the value of adding an additional item to the Windows Start Menu and OS X Applications folder called Add Web Application, which would generate appropriate shortcuts, and grant the Web app additional privileges. I think conceptually this works well since the interface is placed alongside other desktop apps, however this is a bit more aggressive than Firefox usually behaves. While UA defined semantics and behaviors are of course outside of the standardization process of the API, I think the Web as a whole would benefit if we coordinated to deploy a reasonably similar interface for this functionality. -Alex Faaborg On Oct 2, 4:23 pm, Jeremy Orlow jor...@chromium.org wrote: That seems like a good plan. Has anyone ever tried formalizing it and floating it around to other vendors? On Fri, Oct 2, 2009 at 4:11 PM, Ben Goodger (Google) b...@chromium.orgwrote: This relates somewhat to how we'd like people to install web applications. For that we figured a site would publish a manifest in some format (there was some talk about something like the extensions manifest) that specifies all kinds of appy things a site can do, like large icons, protocol schemes and mime types it can handle and the URLs for each, etc etc. The UA would expose some way to activate all of this functionality for a site in one shot... e.g. if the site published the data via some kind of link tag then a menu item in the browser might activate that the user could use to activate it. -Ben On Fri, Oct 2, 2009 at 2:55 PM, Jeremy Orlow jor...@chromium.org wrote: On Fri, Oct 2, 2009 at 2:48 PM, Peter Kasting pkast...@google.com wrote: On Fri, Oct 2, 2009 at 2:47 PM, Jeremy Orlow jor...@chromium.org wrote: Is this API even part of any standard? Maybe we should bring this up on WhatWG? The thread title is a clue that these are specced in HTML5 :) Not really. People abuse the term HTML5. Good example: WebSockets, WebDatabase, LocalStorage, Workers, and many of the other APIs we associate with HTML5 are not in that spec. Anyhow, apparently this was discussed very recently and I somehow missed the discussion: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/02... I'll try to take a look at the thread some time soon. Ben and/or other UI guys, maybe you should too. Now is the time to make noise if we think this is a bad API. J --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: xp purify unit freak out this evening
On Mon, Oct 5, 2009 at 8:18 PM, Matt Mueller ma...@chromium.org wrote: This night xp purify failed with a bunch of new leaks: http://build.chromium.org/buildbot/waterfall/builders/XP%20Unit%20(purify)/builds/5856/steps/purify%20test:%20unit/logs/stdio After looking at the stdio for the 10th time I finally saw that the test didn't exit cleanly, which would explain why atexit and singleton stuff showed up so much in the leaks. Yes, any time the tests crash, you can't trust any memory leak errors from Purify. Unfortunately, so far we haven't found a clean way to detect crashes from these scripts. It gets complicated when there are multiple child processes, etc. The last lines were: [--] 2 tests from DnsMasterTest [ RUN ] DnsMasterTest.ConcurrentLookupTest ERROR:root:src/build\Release\unit_tests.exe exited with non-zero result code -1073741819 Is this sufficient to blame the flakiness on that test, or are the logs buffered so it might have actually died in some other test? This should be sufficient. We collect all of the output from the test and flush it all. So this is the test it crashed on. Erik --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Scalability
On Mon, Oct 05, 2009 at 10:20:47AM -0700, Steven Knight wrote: The variable name is actually just 'library'. The default is set in build/common.gypi. You can either change the default variable right in build/common.gypi or set the environment variable GYP_DEFINES=library=shared_library to get a shared library build. (I have it modified locally in one of my checked-out Linux trees for periodic sanity checks that Linux at least nominally builds with shared libraries. IIRC, a lot of the Linux folks use shared library builds regularly, for the much faster link times.) I tried this, and it does indeed link far, far faster! However, I got errors about RegisterInternalNaClPlugin(): /mnt/sda4/media/contrib/chrome2/home/chrome-svn/tarball/chromium/src/sconsbuild/Debug/lib/librenderer.so: undefined reference to `RegisterInternalNaClPlugin(bool (*)(int, int*))' (Also one for libbrowser.so) I see these are protected by #ifndef DISABLE_NACL and if (command_line.HasSwitch(switches::kInternalNaCl)), but why would that affect things? DISABLE_NACL should be defined or not the same for shared or static build, and the HasSwitch is a run-time check. If I comment them out, then chrome links. But the call is in RenderProcess::RenderProcess(), surely not dead code that the static link would be removing. Any idea what's going on here? -- Jacob --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Developer Tools will be busted in the next Dev Channel Chromium on Linux (my fault), can we work around it?
The problem was introduced in 27980. Commit went fine, because the output wasn't clobbered, but after a WebKit roll we observed that the file doesn't get generated as expected. http://src.chromium.org/viewvc/chrome?view=revrevision=27980 On Tue, Oct 6, 2009 at 19:21, Anthony LaForge lafo...@chromium.org wrote: At what revision was the error introduced? Kind Regards, Anthony Laforge Technical Program Manager Mountain View, CA On Tue, Oct 6, 2009 at 5:11 AM, Mikhail Naganov mnaga...@chromium.org wrote: Hi guys, I'm sorry, but due to my lack of experience with Gyp files, the 221.7 version cut at 28100 will have disfunctional Developer tools. I fixed the problem in 28102 (a three lines fix to gyp file.) Can we somehow patch these changes (or maybe manually add devtools.html into Linux distribution) to avoid having busted DevTools for a week? --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Scalability
On Tue, Oct 6, 2009 at 9:21 AM, Jacob Mandelson ja...@mandelson.org wrote: I tried this, and it does indeed link far, far faster! However, I got errors about RegisterInternalNaClPlugin(): /mnt/sda4/media/contrib/chrome2/home/chrome-svn/tarball/chromium/src/sconsbuild/Debug/lib/librenderer.so: undefined reference to `RegisterInternalNaClPlugin(bool (*)(int, int*))' (Also one for libbrowser.so) In general, the shared link breaks frequently. Whenever I work from a cafe or wherever from my laptop, I usually will do a TBR commit or two to fix the shared link. I see these are protected by #ifndef DISABLE_NACL and if (command_line.HasSwitch(switches::kInternalNaCl)), but why would that affect things? DISABLE_NACL should be defined or not the same for shared or static build, and the HasSwitch is a run-time check. If I comment them out, then chrome links. But the call is in RenderProcess::RenderProcess(), surely not dead code that the static link would be removing. Any idea what's going on here? Perhaps NACL isn't yet working in the shared build. I think NACL is on now, so DISABLE_NACL should be undefined. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Learning Webkit: High Level Webkit overview?
On Sun, Oct 4, 2009 at 8:19 AM, Buakaw San buakaw@gmail.com wrote: There is a document called How Chromium Displays Web Pages (http:// dev.chromium.org/developers/design-documents/displaying-a-web-page-in- chrome), however I haven't found an equivalent page for Webkit. E.g. How Webkit Renders Web Pages. The Chromium document doesn't go into the Webkit part. There is an old blog http://webkit.org/blog/114/webcore-rendering-i-the-basics/. Which talks about some of the render process but it seems to focus on CSS handling. I'm trying to diagram this process. E.g. We're load a simple web page with some body text, a couple divs; one with an image tag, one with a plugin like flash. What is happening from start to finish? I imagine the process like such: Content = HTML Parsing = DOM Construction = Layout (Render Tree Construction) = Rendering That's pretty much spot on. Note that it's not always happening exactly in this order, especially if the document is large and arrives from the server in multiple chunks. Then it could look something like: Some content received HTML parsing (which builds up the DOM as it goes) Some more content received More HTML parsing, DOM construction Layout Rendering (aka painting) What is the first thing that is done? Which class is initially hit when a new web page request arrives? Which classes are responsible for parsing HTML/DOM/CSS? How is the plugin loaded? How is the image loaded? The picture is a bit complex, but I can try to give some pointers for starting. Resources are pulled in through a variety of Loader classes - start with FrameLoader (although it's too complicated at the moment). HTML Content is fed into an HTMLTokenizer which builds up the DOM tree. For images, see ImageLoader. I'm not sure exactly how plugins work. Layout and painting are covered in the Surfin' Safari blog post - if you want to step through them in a debugger start in FrameView. While these are questions that could be answered by studying the code in depth, it would be nice if there was such a basic introduction to Webkit rendering. Ideally one with nice pictures (like the Chromium docs), interaction diagrams and such. Is that volunteering? :) - James Perhaps this thread could become a source of knowledge for new comers. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] buildbot failure in Chromium on Webkit, revision 28123
Automatically closing tree for test_shell_tests on Webkit http://build.chromium.org/buildbot/waterfall/builders/Webkit/builds/12798 http://build.chromium.org/buildbot/waterfall/waterfall?builder=Webkit --= Automatically closing tree for test_shell_tests on Webkit =-- Revision: 28123 Blame list: je...@chromium.org Buildbot waterfall: http://build.chromium.org/ --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] buildbot failure in Chromium on Webkit, revision 28124
Automatically closing tree for test_shell_tests on Webkit http://build.chromium.org/buildbot/waterfall/builders/Webkit/builds/12799 http://build.chromium.org/buildbot/waterfall/waterfall?builder=Webkit --= Automatically closing tree for test_shell_tests on Webkit =-- Revision: 28124 Blame list: atwil...@chromium.org Buildbot waterfall: http://build.chromium.org/ --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Scalability
On Tue, Oct 06, 2009 at 07:39:14PM +0200, Craig Schlenter wrote:
On Tue, Oct 6, 2009 at 6:58 PM, Evan Martin e...@chromium.org wrote:
On Tue, Oct 6, 2009 at 9:21 AM, Jacob Mandelson ja...@mandelson.org wrote:
I tried this, and it does indeed link far, far faster!
However, I got errors about RegisterInternalNaClPlugin():
/mnt/sda4/media/contrib/chrome2/home/chrome-svn/tarball/chromium/src/sconsbuild/Debug/lib/librenderer.so:
undefined reference to `RegisterInternalNaClPlugin(bool (*)(int, int*))'
(Also one for libbrowser.so)
In general, the shared link breaks frequently. Whenever I work from a
cafe or wherever from my laptop, I usually will do a TBR commit or two
to fix the shared link.
The shared build is working perfectly for me FWIW but that is on 32 bit.
Are you on 64 bit or do you have any special gyp variables etc. set?
I'm on 32-bit. Only gyp changes from stock I have are:
{'variables': {
'library': 'shared_library',
'remove_webcore_debug_symbols': 1,
}}
-- Jacob
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] buildbot failure in Chromium on Webkit, revision 0
Automatically closing tree for test_shell_tests on Webkit http://build.chromium.org/buildbot/waterfall/builders/Webkit/builds/12800 http://build.chromium.org/buildbot/waterfall/waterfall?builder=Webkit --= Automatically closing tree for test_shell_tests on Webkit =-- Revision: Blame list: Buildbot waterfall: http://build.chromium.org/ --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Scalability
On Tue, Oct 6, 2009 at 8:14 PM, Craig Schlenter
craig.schlen...@gmail.com wrote:
On Tue, Oct 6, 2009 at 7:51 PM, Jacob Mandelson ja...@mandelson.org wrote:
On Tue, Oct 06, 2009 at 07:39:14PM +0200, Craig Schlenter wrote:
On Tue, Oct 6, 2009 at 6:58 PM, Evan Martin e...@chromium.org wrote:
On Tue, Oct 6, 2009 at 9:21 AM, Jacob Mandelson ja...@mandelson.org
wrote:
I tried this, and it does indeed link far, far faster!
However, I got errors about RegisterInternalNaClPlugin():
/mnt/sda4/media/contrib/chrome2/home/chrome-svn/tarball/chromium/src/sconsbuild/Debug/lib/librenderer.so:
undefined reference to `RegisterInternalNaClPlugin(bool (*)(int, int*))'
(Also one for libbrowser.so)
In general, the shared link breaks frequently. Whenever I work from a
cafe or wherever from my laptop, I usually will do a TBR commit or two
to fix the shared link.
The shared build is working perfectly for me FWIW but that is on 32 bit.
Are you on 64 bit or do you have any special gyp variables etc. set?
I'm on 32-bit. Only gyp changes from stock I have are:
{'variables': {
'library': 'shared_library',
'remove_webcore_debug_symbols': 1,
}}
Ah, you're doing a debug build then? I have only tested release recently.
I'll poke at a debug build tomorrow and try to sort it out ...
Hm ... debug build is also fine for me and I'm building with the
same gyp variables as you (except that I also have gcc_version=44).
If you stick your build into verbose mode can you see if it is linking
librenderer.so with libnpGoogleNaClPluginChrome.a? Maybe clobbering,
regyping etc. will encourage it to do that.
PS. I'm on r28124
--Craig
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] Re: [LTTF] Can someone look at some broad failure categories?
On Tue, Oct 6, 2009 at 1:07 PM, Peter Kasting pkast...@google.com wrote: This is your friendly Chromium sheriff. I've been adding tons of suppressions to test_expectations.txt over the last two days and they mainly fall into three buckets. Could someone take a look at these, please, since there are so many failures?: * LayoutTests/http/tests/ is flakily timing out on Mac (mainly Mac release) * LayoutTests/media/ is failing and/or flaky on all platforms Myself and hclam are your local media layout test people. We're getting slightly different pixel results depending on the position of the sun. We have some WebKit patches underway that address our media rendering so it's safe to keep suppressing the failures. * LayoutTests/transitions/ is flakily failing on Linux Thanks, PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [LTTF] Can someone look at some broad failure categories?
On Tue, Oct 6, 2009 at 1:44 PM, Andrew Scherkus scher...@chromium.orgwrote: We're getting slightly different pixel results depending on the position of the sun. We have some WebKit patches underway that address our media rendering so it's safe to keep suppressing the failures. OK. To be clear, I'm mostly trying to avoid having runs continually turn red and me add more exceptions. If you think all media/ tests are flaky, maybe you should simply gut all the individual test expectations and put in a directory-wide exclusion until things are more stable. PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Scalability
On Tue, Oct 06, 2009 at 09:19:49PM +0200, Craig Schlenter wrote:
On Tue, Oct 6, 2009 at 8:14 PM, Craig Schlenter
craig.schlen...@gmail.com wrote:
On Tue, Oct 6, 2009 at 7:51 PM, Jacob Mandelson ja...@mandelson.org wrote:
On Tue, Oct 06, 2009 at 07:39:14PM +0200, Craig Schlenter wrote:
On Tue, Oct 6, 2009 at 6:58 PM, Evan Martin e...@chromium.org wrote:
On Tue, Oct 6, 2009 at 9:21 AM, Jacob Mandelson ja...@mandelson.org
wrote:
I tried this, and it does indeed link far, far faster!
However, I got errors about RegisterInternalNaClPlugin():
/mnt/sda4/media/contrib/chrome2/home/chrome-svn/tarball/chromium/src/sconsbuild/Debug/lib/librenderer.so:
undefined reference to `RegisterInternalNaClPlugin(bool (*)(int,
int*))'
(Also one for libbrowser.so)
In general, the shared link breaks frequently. Whenever I work from a
cafe or wherever from my laptop, I usually will do a TBR commit or two
to fix the shared link.
The shared build is working perfectly for me FWIW but that is on 32 bit.
Are you on 64 bit or do you have any special gyp variables etc. set?
I'm on 32-bit. Only gyp changes from stock I have are:
{'variables': {
'library': 'shared_library',
'remove_webcore_debug_symbols': 1,
}}
Ah, you're doing a debug build then? I have only tested release recently.
I'll poke at a debug build tomorrow and try to sort it out ...
Hm ... debug build is also fine for me and I'm building with the
same gyp variables as you (except that I also have gcc_version=44).
If you stick your build into verbose mode can you see if it is linking
librenderer.so with libnpGoogleNaClPluginChrome.a? Maybe clobbering,
regyping etc. will encourage it to do that.
PS. I'm on r28124
I switched to --mode=Release, got strict-aliasing warnings^Werrors, stuck
on -Wno-strict-aliasing, and it landed back in
/mnt/sda4/media/contrib/chrome2/home/chrome-svn/tarball/chromium/src/sconsbuild/Release/lib/librenderer.so:
undefined reference to `RegisterInternalNaClPlugin(bool (*)(int, int*))'
Running gclient runhooks had no effect here.
Building with --verbose shows the very long link line attached, which
has [nN][aA][cC][lL] only in -lnacl.
gclient revinfo begins with
src: http://src.chromium.org/svn/trunk/s...@28154;
(Simpler way to get this?)
-- Jacob
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
flock
/mnt/sda4/media/contrib/chrome2/home/chrome-svn/tarball/chromium/src/sconsbuild/Release/linker.lock
g++ -o
/mnt/sda4/media/contrib/chrome2/home/chrome-svn/tarball/chromium/src/sconsbuild/Release/lib/librenderer.so
-L/mnt/sda4/media/contrib/chrome2/home/chrome-svn/tarball/chromium/src/sconsbuild/Release/lib
-Wl,-rpath=/mnt/sda4/media/contrib/chrome2/home/chrome-svn/tarball/chromium/src/sconsbuild/Release/lib
-pthread -m32 -shared -pthread -m32
/mnt/sda4/media/contrib/chrome2/home/chrome-svn/tarball/chromium/src/sconsbuild/Release/obj/chrome/renderer/renderer/automation/dom_automation_controller.os
/mnt/sda4/media/contrib/chrome2/home/chrome-svn/tarball/chromium/src/sconsbuild/Release/obj/chrome/renderer/renderer/extensions/bindings_utils.os
/mnt/sda4/media/contrib/chrome2/home/chrome-svn/tarball/chromium/src/sconsbuild/Release/obj/chrome/renderer/renderer/extensions/event_bindings.os
/mnt/sda4/media/contrib/chrome2/home/chrome-svn/tarball/chromium/src/sconsbuild/Release/obj/chrome/renderer/renderer/extensions/extension_process_bindings.os
/mnt/sda4/media/contrib/chrome2/home/chrome-svn/tarball/chromium/src/sconsbuild/Release/obj/chrome/renderer/renderer/extensions/js_only_v8_extensions.os
/mnt/sda4/media/contrib/chrome2/home/chrome-svn/tarball/chromium/src/sconsbuild/Release/obj/chrome/renderer/renderer/extensions/renderer_extension_bindings.os
/mnt/sda4/media/contrib/chrome2/home/chrome-svn/tarball/chromium/src/sconsbuild/Release/obj/chrome/renderer/renderer/loadtimes_extension_bindings.os
/mnt/sda4/media/contrib/chrome2/home/chrome-svn/tarball/chromium/src/sconsbuild/Release/obj/chrome/renderer/renderer/media/audio_renderer_impl.os
/mnt/sda4/media/contrib/chrome2/home/chrome-svn/tarball/chromium/src/sconsbuild/Release/obj/chrome/renderer/renderer/net/render_dns_master.os
/mnt/sda4/media/contrib/chrome2/home/chrome-svn/tarball/chromium/src/sconsbuild/Release/obj/chrome/renderer/renderer/net/render_dns_queue.os
/mnt/sda4/media/contrib/chrome2/home/chrome-svn/tarball/chromium/src/sconsbuild/Release/obj/chrome/renderer/renderer/about_handler.os
/mnt/sda4/media/contrib/chrome2/home/chrome-svn/tarball/chromium/src/sconsbuild/Release/obj/chrome/renderer/renderer/audio_message_filter.os
[chromium-dev] Re: [LTTF] Can someone look at some broad failure categories?
On Tue, Oct 6, 2009 at 1:49 PM, Peter Kasting pkast...@google.com wrote: On Tue, Oct 6, 2009 at 1:44 PM, Andrew Scherkus scher...@chromium.orgwrote: We're getting slightly different pixel results depending on the position of the sun. We have some WebKit patches underway that address our media rendering so it's safe to keep suppressing the failures. OK. To be clear, I'm mostly trying to avoid having runs continually turn red and me add more exceptions. If you think all media/ tests are flaky, maybe you should simply gut all the individual test expectations and put in a directory-wide exclusion until things are more stable. http://src.chromium.org/viewvc/chrome/trunk/src/webkit/tools/layout_tests/flakiness_dashboard.html#tests=LayoutTests/media Should give a pretty good sense of which media tests are flaky. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Converting dialogs to infobars
Multidownload infobar SGTM, though I'm pretty sure I've seen the multiple download dialog appear after user input (could be for downloads initiated via JS or iframe POSTS). Though given that that's the minority case, infobar is fine. External protocol dialog should remain a dialog - I see it whenever I click on links to stuff in the iTunes store, and having it show as an infobar would be unpleasant. Chatted briefly w/Brian he seemed to agree about multiple download dialog, Glen what do you think? -Ben On Tue, Oct 6, 2009 at 3:02 PM, Evan Stade est...@chromium.org wrote: On Tue, Oct 6, 2009 at 1:12 PM, Ben Goodger (Google) b...@chromium.org wrote: We should only use infobars for things that aren't initiated by a user action. They are very confusing for user initiated actions since they are harder to notice. In each of these cases, can you determine whether or not a user action caused them? for the multiple download dialog, a user action definitely did not cause it. for the external protocol handler, a user action usually did cause it (but sometimes not). I don't think there's any way of knowing for sure. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Converting dialogs to infobars
On Tue, Oct 6, 2009 at 6:18 PM, Glen Murphy g...@chromium.org wrote: External protocol dialog should remain a dialog - I see it whenever I click on links to stuff in the iTunes store, and having it show as an infobar would be unpleasant. OT: Use the Mac version; you can set the always allow this protocol checkbox. Avi --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Converting dialogs to infobars
Can you make sure a bug is filed to get this into the other platforms? -Ben On Tue, Oct 6, 2009 at 3:20 PM, Avi Drissman a...@chromium.org wrote: On Tue, Oct 6, 2009 at 6:18 PM, Glen Murphy g...@chromium.org wrote: External protocol dialog should remain a dialog - I see it whenever I click on links to stuff in the iTunes store, and having it show as an infobar would be unpleasant. OT: Use the Mac version; you can set the always allow this protocol checkbox. Avi --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Converting dialogs to infobars
Will do first thing tomorrow. Avi /who figured it was OK since the string was already in the grd file On Tue, Oct 6, 2009 at 6:25 PM, Ben Goodger (Google) b...@chromium.orgwrote: Can you make sure a bug is filed to get this into the other platforms? -Ben On Tue, Oct 6, 2009 at 3:20 PM, Avi Drissman a...@chromium.org wrote: On Tue, Oct 6, 2009 at 6:18 PM, Glen Murphy g...@chromium.org wrote: External protocol dialog should remain a dialog - I see it whenever I click on links to stuff in the iTunes store, and having it show as an infobar would be unpleasant. OT: Use the Mac version; you can set the always allow this protocol checkbox. Avi --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Converting dialogs to infobars
It's great to re-use strings where it seems elegant. We should make sure our UX matches in substance on all platforms. This is especially important for help center docs, which may screenshot one platform. -Ben On Tue, Oct 6, 2009 at 3:30 PM, Avi Drissman a...@chromium.org wrote: Will do first thing tomorrow. Avi /who figured it was OK since the string was already in the grd file On Tue, Oct 6, 2009 at 6:25 PM, Ben Goodger (Google) b...@chromium.org wrote: Can you make sure a bug is filed to get this into the other platforms? -Ben On Tue, Oct 6, 2009 at 3:20 PM, Avi Drissman a...@chromium.org wrote: On Tue, Oct 6, 2009 at 6:18 PM, Glen Murphy g...@chromium.org wrote: External protocol dialog should remain a dialog - I see it whenever I click on links to stuff in the iTunes store, and having it show as an infobar would be unpleasant. OT: Use the Mac version; you can set the always allow this protocol checkbox. Avi --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Converting dialogs to infobars
On Tue, Oct 6, 2009 at 3:18 PM, Glen Murphy g...@chromium.org wrote: Multidownload infobar SGTM, though I'm pretty sure I've seen the multiple download dialog appear after user input (could be for downloads initiated via JS or iframe POSTS). The multidownload dialog is launched specifically when there was a download started without user input, where user input == enter, space or click anywhere in the page, so it doesn't matter by which mechanism the download is initiated; it just matters whether the user did something. This is of course racy and heuristic. External protocol dialog should remain a dialog - I see it whenever I click on links to stuff in the iTunes store, and having it show as an infobar would be unpleasant. Chatted briefly w/Brian he seemed to agree about multiple download dialog, Glen what do you think? -Ben On Tue, Oct 6, 2009 at 3:02 PM, Evan Stade est...@chromium.org wrote: On Tue, Oct 6, 2009 at 1:12 PM, Ben Goodger (Google) b...@chromium.org wrote: We should only use infobars for things that aren't initiated by a user action. They are very confusing for user initiated actions since they are harder to notice. In each of these cases, can you determine whether or not a user action caused them? for the multiple download dialog, a user action definitely did not cause it. for the external protocol handler, a user action usually did cause it (but sometimes not). I don't think there's any way of knowing for sure. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Converting dialogs to infobars
OK let's make the change for multiple downloads, but not for protocols. If you fix the bug on linux, please make sure the bug is filed for mac/windows. Thanks! -Ben On Tue, Oct 6, 2009 at 3:37 PM, Evan Stade est...@chromium.org wrote: On Tue, Oct 6, 2009 at 3:18 PM, Glen Murphy g...@chromium.org wrote: Multidownload infobar SGTM, though I'm pretty sure I've seen the multiple download dialog appear after user input (could be for downloads initiated via JS or iframe POSTS). The multidownload dialog is launched specifically when there was a download started without user input, where user input == enter, space or click anywhere in the page, so it doesn't matter by which mechanism the download is initiated; it just matters whether the user did something. This is of course racy and heuristic. External protocol dialog should remain a dialog - I see it whenever I click on links to stuff in the iTunes store, and having it show as an infobar would be unpleasant. Chatted briefly w/Brian he seemed to agree about multiple download dialog, Glen what do you think? -Ben On Tue, Oct 6, 2009 at 3:02 PM, Evan Stade est...@chromium.org wrote: On Tue, Oct 6, 2009 at 1:12 PM, Ben Goodger (Google) b...@chromium.org wrote: We should only use infobars for things that aren't initiated by a user action. They are very confusing for user initiated actions since they are harder to notice. In each of these cases, can you determine whether or not a user action caused them? for the multiple download dialog, a user action definitely did not cause it. for the external protocol handler, a user action usually did cause it (but sometimes not). I don't think there's any way of knowing for sure. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] buildbot failure in Chromium on Chromium Linux x64, revision 28166
Automatically closing tree for compile on Chromium Linux x64 http://build.chromium.org/buildbot/waterfall/builders/Chromium%20Linux%20x64/builds/960 http://build.chromium.org/buildbot/waterfall/waterfall?builder=Chromium%20Linux%20x64 --= Automatically closing tree for compile on Chromium Linux x64 =-- Revision: 28166 Blame list: tschmelc...@google.com Buildbot waterfall: http://build.chromium.org/ --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Paper about DRAM error rates
Saw this on slashdot: http://www.cs.toronto.edu/~bianca/papers/sigmetrics09.pdf The conclusion is an average of 25,000–75,000 FIT (failures in time per billion hours of operation) per Mbit. On my machine the browser process is usually 100MB, so that averages out to 176 to 493 error per year, with those numbers having big variance depending on the machine. Since most users don't have ECC, which means this will lead to corruption. Sqlite is a heavy user of memory, so even if it's 1/4 of the 100MB, that means we'll see an average of 40-120 errors naturally because of faulty DIMMs. Given that sqlite corruption means (repeated) crashing of the browser process, it seems this data heavily suggests we should separate sqlite code into a separate process. The IPC overhead is negligible compared to disk access. My hunch is that the complexity is also not that high, since the code that deals with it is already asynchronous since we don't use sqlite on the UI/IO threads. What do others think? --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Paper about DRAM error rates
It will be helpful to get our own measurement on database failures. Carlos just added something like that. Huan On Tue, Oct 6, 2009 at 3:49 PM, John Abd-El-Malek j...@chromium.org wrote: Saw this on slashdot: http://www.cs.toronto.edu/~bianca/papers/sigmetrics09.pdf The conclusion is an average of 25,000–75,000 FIT (failures in time per billion hours of operation) per Mbit. On my machine the browser process is usually 100MB, so that averages out to 176 to 493 error per year, with those numbers having big variance depending on the machine. Since most users don't have ECC, which means this will lead to corruption. Sqlite is a heavy user of memory, so even if it's 1/4 of the 100MB, that means we'll see an average of 40-120 errors naturally because of faulty DIMMs. Given that sqlite corruption means (repeated) crashing of the browser process, it seems this data heavily suggests we should separate sqlite code into a separate process. The IPC overhead is negligible compared to disk access. My hunch is that the complexity is also not that high, since the code that deals with it is already asynchronous since we don't use sqlite on the UI/IO threads. What do others think? --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] buildbot failure in Chromium on Chromium Linux x64, revision 28168
Automatically closing tree for compile on Chromium Linux x64 http://build.chromium.org/buildbot/waterfall/builders/Chromium%20Linux%20x64/builds/962 http://build.chromium.org/buildbot/waterfall/waterfall?builder=Chromium%20Linux%20x64 --= Automatically closing tree for compile on Chromium Linux x64 =-- Revision: 28168 Blame list: pkast...@chromium.org Buildbot waterfall: http://build.chromium.org/ --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Paper about DRAM error rates
I'm not sure how Carlos is doing it? Will we know if something is corrupt just on load/save? I imagine there's no way we can know when corruption happen in steady-state and the next query leads to some other browser memory (or another database) getting corrupted? On Tue, Oct 6, 2009 at 3:58 PM, Huan Ren hu...@google.com wrote: It will be helpful to get our own measurement on database failures. Carlos just added something like that. Huan On Tue, Oct 6, 2009 at 3:49 PM, John Abd-El-Malek j...@chromium.org wrote: Saw this on slashdot: http://www.cs.toronto.edu/~bianca/papers/sigmetrics09.pdf The conclusion is an average of 25,000–75,000 FIT (failures in time per billion hours of operation) per Mbit. On my machine the browser process is usually 100MB, so that averages out to 176 to 493 error per year, with those numbers having big variance depending on the machine. Since most users don't have ECC, which means this will lead to corruption. Sqlite is a heavy user of memory, so even if it's 1/4 of the 100MB, that means we'll see an average of 40-120 errors naturally because of faulty DIMMs. Given that sqlite corruption means (repeated) crashing of the browser process, it seems this data heavily suggests we should separate sqlite code into a separate process. The IPC overhead is negligible compared to disk access. My hunch is that the complexity is also not that high, since the code that deals with it is already asynchronous since we don't use sqlite on the UI/IO threads. What do others think? --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Paper about DRAM error rates
On Tue, Oct 6, 2009 at 4:30 PM, Carlos Pizano c...@google.com wrote: On Tue, Oct 6, 2009 at 4:14 PM, John Abd-El-Malek j...@chromium.org wrote: I'm not sure how Carlos is doing it? Will we know if something is corrupt just on load/save? Many sqlite calls can return sqlite_corrupt. For example a query or an insert We just check for error codes 1 to 26 with 5 or 6 of them being serious error such as sqlite_corrupt I am sure that random bit flip in memory and on disk is the cause of some crashes, this is probably the 'limit' factor of how low the crash rate of a perfect program deployed in millions of computers can go. The point I was trying to make is that the 'limit' factor as you put it is proportional to memory usage. Given our large memory consumption in the browser process, the numbers from the paper imply dozens of corruptions just in sqlite memory per user. Even if only a small fraction of these are harmful, spread over millions of users that's a lot of corruption. But I am unsure how to calculate, for example a random bit flip on the backingstores, which add to at least 10M on most machines does not hurt, or in the middle of a cache entry, or in the data part of some structure. I imagine there's no way we can know when corruption happen in steady-state and the next query leads to some other browser memory (or another database) getting corrupted? On Tue, Oct 6, 2009 at 3:58 PM, Huan Ren hu...@google.com wrote: It will be helpful to get our own measurement on database failures. Carlos just added something like that. Huan On Tue, Oct 6, 2009 at 3:49 PM, John Abd-El-Malek j...@chromium.org wrote: Saw this on slashdot: http://www.cs.toronto.edu/~bianca/papers/sigmetrics09.pdf The conclusion is an average of 25,000–75,000 FIT (failures in time per billion hours of operation) per Mbit. On my machine the browser process is usually 100MB, so that averages out to 176 to 493 error per year, with those numbers having big variance depending on the machine. Since most users don't have ECC, which means this will lead to corruption. Sqlite is a heavy user of memory, so even if it's 1/4 of the 100MB, that means we'll see an average of 40-120 errors naturally because of faulty DIMMs. Given that sqlite corruption means (repeated) crashing of the browser process, it seems this data heavily suggests we should separate sqlite code into a separate process. The IPC overhead is negligible compared to disk access. My hunch is that the complexity is also not that high, since the code that deals with it is already asynchronous since we don't use sqlite on the UI/IO threads. What do others think? --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] How to deal with flaky unit tests
Hello, We currently have more than 50 unit tests that are disabled. Most of them because they were flaky. Disabling tests is bad because we lose complete coverage on them, so I implemented a way to mark tests as flaky. The same way you disable a test with DISABLED_ at the beginning of its name, you can now mark is as flaky with FLAKY_. The behavior is exactly the same as any other running tests. You will still be able to see when it fails (and why). The only difference is that if only FLAKY_ tests failed, the buildbot/trybots won't consider it as a failure. On the waterfall, it will show the box as orange with the list of all flaky tests that failed (pending one more buildbot restart). On the console view it will stay green. But.. this is not a toy. Flaky tests are bad. We should mark tests flaky only if we really have to, and if you do, please make sure to file a P1 bug. Set the owner of the bug to whoever regressed the test. If you can't find who regressed the test, assign it to the person who originally wrote the test. Once we start tagging the flaky tests, we will monitor the flakiness dashboard and make sure that a test that is no longer flaky has its FLAKY_ tag removed. Let me know if you have questions. Thanks Nicolas --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Paper about DRAM error rates
Our use of exclusive locking and page-cache preloading may open us up more to this kind of shenanigans. Basically SQLite will trust those pages which we faulted into memory days ago. We could mitigate against that somewhat, but this problem reaches into areas we cannot materially impact, such as filesystem caches. And don't even begin to imagine that there are not similar issues with commodity disk drives and controllers. That said, I don't think this is an incremental addition of any kind. I've pointed it out before, there are things in the woods which corrupt databases. We could MAYBE reduce occurrences to a suitable minimum using check-summing or something of the sort, but in the end we still have to detect corruption and decide what course to take from there. -scott On Tue, Oct 6, 2009 at 4:59 PM, John Abd-El-Malek j...@chromium.org wrote: On Tue, Oct 6, 2009 at 4:30 PM, Carlos Pizano c...@google.com wrote: On Tue, Oct 6, 2009 at 4:14 PM, John Abd-El-Malek j...@chromium.org wrote: I'm not sure how Carlos is doing it? Will we know if something is corrupt just on load/save? Many sqlite calls can return sqlite_corrupt. For example a query or an insert We just check for error codes 1 to 26 with 5 or 6 of them being serious error such as sqlite_corrupt I am sure that random bit flip in memory and on disk is the cause of some crashes, this is probably the 'limit' factor of how low the crash rate of a perfect program deployed in millions of computers can go. The point I was trying to make is that the 'limit' factor as you put it is proportional to memory usage. Given our large memory consumption in the browser process, the numbers from the paper imply dozens of corruptions just in sqlite memory per user. Even if only a small fraction of these are harmful, spread over millions of users that's a lot of corruption. But I am unsure how to calculate, for example a random bit flip on the backingstores, which add to at least 10M on most machines does not hurt, or in the middle of a cache entry, or in the data part of some structure. I imagine there's no way we can know when corruption happen in steady-state and the next query leads to some other browser memory (or another database) getting corrupted? On Tue, Oct 6, 2009 at 3:58 PM, Huan Ren hu...@google.com wrote: It will be helpful to get our own measurement on database failures. Carlos just added something like that. Huan On Tue, Oct 6, 2009 at 3:49 PM, John Abd-El-Malek j...@chromium.org wrote: Saw this on slashdot: http://www.cs.toronto.edu/~bianca/papers/sigmetrics09.pdf The conclusion is an average of 25,000–75,000 FIT (failures in time per billion hours of operation) per Mbit. On my machine the browser process is usually 100MB, so that averages out to 176 to 493 error per year, with those numbers having big variance depending on the machine. Since most users don't have ECC, which means this will lead to corruption. Sqlite is a heavy user of memory, so even if it's 1/4 of the 100MB, that means we'll see an average of 40-120 errors naturally because of faulty DIMMs. Given that sqlite corruption means (repeated) crashing of the browser process, it seems this data heavily suggests we should separate sqlite code into a separate process. The IPC overhead is negligible compared to disk access. My hunch is that the complexity is also not that high, since the code that deals with it is already asynchronous since we don't use sqlite on the UI/IO threads. What do others think? --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Paper about DRAM error rates
On Tue, Oct 6, 2009 at 4:59 PM, John Abd-El-Malek j...@chromium.org wrote: On Tue, Oct 6, 2009 at 4:30 PM, Carlos Pizano c...@google.com wrote: On Tue, Oct 6, 2009 at 4:14 PM, John Abd-El-Malek j...@chromium.org wrote: I'm not sure how Carlos is doing it? Will we know if something is corrupt just on load/save? Many sqlite calls can return sqlite_corrupt. For example a query or an insert We just check for error codes 1 to 26 with 5 or 6 of them being serious error such as sqlite_corrupt I am sure that random bit flip in memory and on disk is the cause of some crashes, this is probably the 'limit' factor of how low the crash rate of a perfect program deployed in millions of computers can go. The point I was trying to make is that the 'limit' factor as you put it is proportional to memory usage. Given our large memory consumption in the browser process, the numbers from the paper imply dozens of corruptions just in sqlite memory per user. Even if only a small fraction of these are harmful, spread over millions of users that's a lot of corruption. For what it's worth: This makes sense to me. It seems like pulling SQLite into its own process would be helpful for the reasons you laid out. I wonder if the only reason no one else has chimed in on this thread is that no one wants to have to implement it. :-) But I am unsure how to calculate, for example a random bit flip on the backingstores, which add to at least 10M on most machines does not hurt, or in the middle of a cache entry, or in the data part of some structure. I imagine there's no way we can know when corruption happen in steady-state and the next query leads to some other browser memory (or another database) getting corrupted? On Tue, Oct 6, 2009 at 3:58 PM, Huan Ren hu...@google.com wrote: It will be helpful to get our own measurement on database failures. Carlos just added something like that. Huan On Tue, Oct 6, 2009 at 3:49 PM, John Abd-El-Malek j...@chromium.org wrote: Saw this on slashdot: http://www.cs.toronto.edu/~bianca/papers/sigmetrics09.pdf The conclusion is an average of 25,000–75,000 FIT (failures in time per billion hours of operation) per Mbit. On my machine the browser process is usually 100MB, so that averages out to 176 to 493 error per year, with those numbers having big variance depending on the machine. Since most users don't have ECC, which means this will lead to corruption. Sqlite is a heavy user of memory, so even if it's 1/4 of the 100MB, that means we'll see an average of 40-120 errors naturally because of faulty DIMMs. Given that sqlite corruption means (repeated) crashing of the browser process, it seems this data heavily suggests we should separate sqlite code into a separate process. The IPC overhead is negligible compared to disk access. My hunch is that the complexity is also not that high, since the code that deals with it is already asynchronous since we don't use sqlite on the UI/IO threads. What do others think? --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Paper about DRAM error rates
On Tue, Oct 6, 2009 at 5:09 PM, Jeremy Orlow jor...@chromium.org wrote: On Tue, Oct 6, 2009 at 4:59 PM, John Abd-El-Malek j...@chromium.orgwrote: On Tue, Oct 6, 2009 at 4:30 PM, Carlos Pizano c...@google.com wrote: On Tue, Oct 6, 2009 at 4:14 PM, John Abd-El-Malek j...@chromium.org wrote: I'm not sure how Carlos is doing it? Will we know if something is corrupt just on load/save? Many sqlite calls can return sqlite_corrupt. For example a query or an insert We just check for error codes 1 to 26 with 5 or 6 of them being serious error such as sqlite_corrupt I am sure that random bit flip in memory and on disk is the cause of some crashes, this is probably the 'limit' factor of how low the crash rate of a perfect program deployed in millions of computers can go. The point I was trying to make is that the 'limit' factor as you put it is proportional to memory usage. Given our large memory consumption in the browser process, the numbers from the paper imply dozens of corruptions just in sqlite memory per user. Even if only a small fraction of these are harmful, spread over millions of users that's a lot of corruption. For what it's worth: This makes sense to me. It seems like pulling SQLite into its own process would be helpful for the reasons you laid out. I wonder if the only reason no one else has chimed in on this thread is that no one wants to have to implement it. :-) Chase is going to start investigating it (i.e. figure out what the cost in doing it is, how much change it requires and ways of measuring the benefit). But I am unsure how to calculate, for example a random bit flip on the backingstores, which add to at least 10M on most machines does not hurt, or in the middle of a cache entry, or in the data part of some structure. I imagine there's no way we can know when corruption happen in steady-state and the next query leads to some other browser memory (or another database) getting corrupted? On Tue, Oct 6, 2009 at 3:58 PM, Huan Ren hu...@google.com wrote: It will be helpful to get our own measurement on database failures. Carlos just added something like that. Huan On Tue, Oct 6, 2009 at 3:49 PM, John Abd-El-Malek j...@chromium.org wrote: Saw this on slashdot: http://www.cs.toronto.edu/~bianca/papers/sigmetrics09.pdf The conclusion is an average of 25,000–75,000 FIT (failures in time per billion hours of operation) per Mbit. On my machine the browser process is usually 100MB, so that averages out to 176 to 493 error per year, with those numbers having big variance depending on the machine. Since most users don't have ECC, which means this will lead to corruption. Sqlite is a heavy user of memory, so even if it's 1/4 of the 100MB, that means we'll see an average of 40-120 errors naturally because of faulty DIMMs. Given that sqlite corruption means (repeated) crashing of the browser process, it seems this data heavily suggests we should separate sqlite code into a separate process. The IPC overhead is negligible compared to disk access. My hunch is that the complexity is also not that high, since the code that deals with it is already asynchronous since we don't use sqlite on the UI/IO threads. What do others think? --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Paper about DRAM error rates
On Tue, Oct 6, 2009 at 5:09 PM, Jeremy Orlow jor...@chromium.org wrote: On Tue, Oct 6, 2009 at 4:59 PM, John Abd-El-Malek j...@chromium.org wrote: On Tue, Oct 6, 2009 at 4:30 PM, Carlos Pizano c...@google.com wrote: On Tue, Oct 6, 2009 at 4:14 PM, John Abd-El-Malek j...@chromium.org wrote: I'm not sure how Carlos is doing it? Will we know if something is corrupt just on load/save? Many sqlite calls can return sqlite_corrupt. For example a query or an insert We just check for error codes 1 to 26 with 5 or 6 of them being serious error such as sqlite_corrupt I am sure that random bit flip in memory and on disk is the cause of some crashes, this is probably the 'limit' factor of how low the crash rate of a perfect program deployed in millions of computers can go. The point I was trying to make is that the 'limit' factor as you put it is proportional to memory usage. Given our large memory consumption in the browser process, the numbers from the paper imply dozens of corruptions just in sqlite memory per user. Even if only a small fraction of these are harmful, spread over millions of users that's a lot of corruption. For what it's worth: This makes sense to me. It seems like pulling SQLite into its own process would be helpful for the reasons you laid out. I wonder if the only reason no one else has chimed in on this thread is that no one wants to have to implement it. :-) I don't understand how this paper makes it very useful to pull SQLite into a separate process. I can see how it would make it useful to minimize how much in-memory data SQLite keeps, regardless of where SQLite lives. I can also see how this effect would increase our incidence of memory stompers, but in a lot of cases it just won't matter. If it corrupts a piece of data which we pass to SQLite, passing it direct or via IPC won't change that. Most memory stompers won't manifest by hitting SQLite anyhow, unless there's reason to believe specific bits will be munged. -scott --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Paper about DRAM error rates
On Tue, Oct 6, 2009 at 5:10 PM, Scott Hess sh...@chromium.org wrote: Our use of exclusive locking and page-cache preloading may open us up more to this kind of shenanigans. Basically SQLite will trust those pages which we faulted into memory days ago. We could mitigate against that somewhat, but this problem reaches into areas we cannot materially impact, such as filesystem caches. And don't even begin to imagine that there are not similar issues with commodity disk drives and controllers. That said, I don't think this is an incremental addition of any kind. I've pointed it out before, there are things in the woods which corrupt databases. We could MAYBE reduce occurrences to a suitable minimum using check-summing or something of the sort, but in the end we still have to detect corruption and decide what course to take from there. I do think these are two separate problems. Personally, I don't care as much if my history or any other database is corrupted and I start from scratch. But random crashes that I can't isolate is something else. -scott On Tue, Oct 6, 2009 at 4:59 PM, John Abd-El-Malek j...@chromium.org wrote: On Tue, Oct 6, 2009 at 4:30 PM, Carlos Pizano c...@google.com wrote: On Tue, Oct 6, 2009 at 4:14 PM, John Abd-El-Malek j...@chromium.org wrote: I'm not sure how Carlos is doing it? Will we know if something is corrupt just on load/save? Many sqlite calls can return sqlite_corrupt. For example a query or an insert We just check for error codes 1 to 26 with 5 or 6 of them being serious error such as sqlite_corrupt I am sure that random bit flip in memory and on disk is the cause of some crashes, this is probably the 'limit' factor of how low the crash rate of a perfect program deployed in millions of computers can go. The point I was trying to make is that the 'limit' factor as you put it is proportional to memory usage. Given our large memory consumption in the browser process, the numbers from the paper imply dozens of corruptions just in sqlite memory per user. Even if only a small fraction of these are harmful, spread over millions of users that's a lot of corruption. But I am unsure how to calculate, for example a random bit flip on the backingstores, which add to at least 10M on most machines does not hurt, or in the middle of a cache entry, or in the data part of some structure. I imagine there's no way we can know when corruption happen in steady-state and the next query leads to some other browser memory (or another database) getting corrupted? On Tue, Oct 6, 2009 at 3:58 PM, Huan Ren hu...@google.com wrote: It will be helpful to get our own measurement on database failures. Carlos just added something like that. Huan On Tue, Oct 6, 2009 at 3:49 PM, John Abd-El-Malek j...@chromium.org wrote: Saw this on slashdot: http://www.cs.toronto.edu/~bianca/papers/sigmetrics09.pdf The conclusion is an average of 25,000–75,000 FIT (failures in time per billion hours of operation) per Mbit. On my machine the browser process is usually 100MB, so that averages out to 176 to 493 error per year, with those numbers having big variance depending on the machine. Since most users don't have ECC, which means this will lead to corruption. Sqlite is a heavy user of memory, so even if it's 1/4 of the 100MB, that means we'll see an average of 40-120 errors naturally because of faulty DIMMs. Given that sqlite corruption means (repeated) crashing of the browser process, it seems this data heavily suggests we should separate sqlite code into a separate process. The IPC overhead is negligible compared to disk access. My hunch is that the complexity is also not that high, since the code that deals with it is already asynchronous since we don't use sqlite on the UI/IO threads. What do others think? --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Paper about DRAM error rates
On Tue, Oct 6, 2009 at 5:16 PM, Scott Hess sh...@chromium.org wrote: On Tue, Oct 6, 2009 at 5:09 PM, Jeremy Orlow jor...@chromium.org wrote: On Tue, Oct 6, 2009 at 4:59 PM, John Abd-El-Malek j...@chromium.org wrote: On Tue, Oct 6, 2009 at 4:30 PM, Carlos Pizano c...@google.com wrote: On Tue, Oct 6, 2009 at 4:14 PM, John Abd-El-Malek j...@chromium.org wrote: I'm not sure how Carlos is doing it? Will we know if something is corrupt just on load/save? Many sqlite calls can return sqlite_corrupt. For example a query or an insert We just check for error codes 1 to 26 with 5 or 6 of them being serious error such as sqlite_corrupt I am sure that random bit flip in memory and on disk is the cause of some crashes, this is probably the 'limit' factor of how low the crash rate of a perfect program deployed in millions of computers can go. The point I was trying to make is that the 'limit' factor as you put it is proportional to memory usage. Given our large memory consumption in the browser process, the numbers from the paper imply dozens of corruptions just in sqlite memory per user. Even if only a small fraction of these are harmful, spread over millions of users that's a lot of corruption. For what it's worth: This makes sense to me. It seems like pulling SQLite into its own process would be helpful for the reasons you laid out. I wonder if the only reason no one else has chimed in on this thread is that no one wants to have to implement it. :-) I don't understand how this paper makes it very useful to pull SQLite into a separate process. I can see how it would make it useful to minimize how much in-memory data SQLite keeps, regardless of where SQLite lives. I can also see how this effect would increase our incidence of memory stompers, but in a lot of cases it just won't matter. If it corrupts a piece of data which we pass to SQLite, passing it direct or via IPC won't change that. Most memory stompers won't manifest by hitting SQLite anyhow, unless there's reason to believe specific bits will be munged. You would only pass POD over IPC, the same which is passed using Task objects across threads. So the only corruption you'll get over IPC would be data corruption, but you ensure that crashes due to corruption are isolated to the sqlite process. -scott --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: How to deal with flaky unit tests
Great stuff! Good work Nicolas. Erik On Tue, Oct 6, 2009 at 5:02 PM, Nicolas Sylvain nsylv...@chromium.org wrote: Hello, We currently have more than 50 unit tests that are disabled. Most of them because they were flaky. Disabling tests is bad because we lose complete coverage on them, so I implemented a way to mark tests as flaky. The same way you disable a test with DISABLED_ at the beginning of its name, you can now mark is as flaky with FLAKY_. The behavior is exactly the same as any other running tests. You will still be able to see when it fails (and why). The only difference is that if only FLAKY_ tests failed, the buildbot/trybots won't consider it as a failure. On the waterfall, it will show the box as orange with the list of all flaky tests that failed (pending one more buildbot restart). On the console view it will stay green. But.. this is not a toy. Flaky tests are bad. We should mark tests flaky only if we really have to, and if you do, please make sure to file a P1 bug. Set the owner of the bug to whoever regressed the test. If you can't find who regressed the test, assign it to the person who originally wrote the test. Once we start tagging the flaky tests, we will monitor the flakiness dashboard and make sure that a test that is no longer flaky has its FLAKY_ tag removed. Let me know if you have questions. Thanks Nicolas --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Paper about DRAM error rates
On Tue, Oct 6, 2009 at 4:59 PM, John Abd-El-Malek j...@chromium.org wrote: The point I was trying to make is that the 'limit' factor as you put it is proportional to memory usage. Given our large memory consumption in the browser process, the numbers from the paper imply dozens of corruptions just in sqlite memory per user. The paper (which is great!) says that error rates are proportional to active use. How busy is the average user's system? I'll bet it's idle 99% of the time. So instead of 4000 or 8000 memory errors per year per machine, one might have 40 or 80. That's still a pretty scary number. Conclusions: 1) zfs was right: checksums are a good idea. Can we add them to sqlite? 2) isolating sqlite into its own process seems like a good idea anyway if it crashes a lot 3) congress should pass a law requiring all personal computers to use error correcting memory and mandating free replacement of DIMMs that have uncorrectable errors :-) --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Paper about DRAM error rates
On Tue, Oct 6, 2009 at 3:49 PM, John Abd-El-Malek j...@chromium.org wrote: Given that sqlite corruption means (repeated) crashing of the browser process, it seems this data heavily suggests we should separate sqlite code into a separate process. What does this mean for cases like the in-memory URL database, which is sqlite code running on a completely in-memory dataset? This is currently used synchronously inside the UI threas to do things like inline autocomplete. We _cannot_ make it async or move it to another thread. So are you proposing to move _some_ sqlite accesses elsewhere? (Personally, I don't think this paper is evidence that we should move sqlite into a separate process, for similar reasons as to Scott.) PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Paper about DRAM error rates
On Tue, Oct 6, 2009 at 5:24 PM, Dan Kegel d...@kegel.com wrote: 1) zfs was right: checksums are a good idea. Can we add them to sqlite? I believe so, but I'm still working through the details. And by working I mean thinking. The challenge is in finding places to tuck things away where they won't break compatibility. I _think_ we could tuck page-level checksums into unused space w/in the page (and arrange for unused space to exist). Then row-level checksums to handle overflow pages (which I don't think allow the same unused-space trick). I haven't dug in to figure out the free list. Note, though, that checksums only get you so far, the real challenge might be in finding all the places to check the checksums. Checking them at read time is unsatisfactory, given this research! -scott --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Paper about DRAM error rates
Out of curiosity does Firefox do anything special w/ regard to how they manage Sqlite? I can't imagine this problem is totally unique to us. Kind Regards, Anthony Laforge Technical Program Manager Mountain View, CA On Tue, Oct 6, 2009 at 5:35 PM, Scott Hess sh...@chromium.org wrote: On Tue, Oct 6, 2009 at 5:24 PM, Dan Kegel d...@kegel.com wrote: 1) zfs was right: checksums are a good idea. Can we add them to sqlite? I believe so, but I'm still working through the details. And by working I mean thinking. The challenge is in finding places to tuck things away where they won't break compatibility. I _think_ we could tuck page-level checksums into unused space w/in the page (and arrange for unused space to exist). Then row-level checksums to handle overflow pages (which I don't think allow the same unused-space trick). I haven't dug in to figure out the free list. Note, though, that checksums only get you so far, the real challenge might be in finding all the places to check the checksums. Checking them at read time is unsatisfactory, given this research! -scott --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Paper about DRAM error rates
On Tue, Oct 6, 2009 at 5:30 PM, Peter Kasting pkast...@google.com wrote: On Tue, Oct 6, 2009 at 3:49 PM, John Abd-El-Malek j...@chromium.orgwrote: Given that sqlite corruption means (repeated) crashing of the browser process, it seems this data heavily suggests we should separate sqlite code into a separate process. What does this mean for cases like the in-memory URL database, which is sqlite code running on a completely in-memory dataset? This is currently used synchronously inside the UI threas to do things like inline autocomplete. We _cannot_ make it async or move it to another thread. So are you proposing to move _some_ sqlite accesses elsewhere? I'm not sure, I think this is one of the questions that needs to be explored more by whoever investigates this. If corruption in the in-memory URL database doesn't survive a crash (i.e. because it's recreated each time), then perhaps it's ok to keep it in the browser process. However, if it's not, I'm not sure I understand why moving it to another process is unworkable? Chrome code is littered with many examples of how we turned synchronous operations into asynchronous ones. But if worst comes to worst and we can't, you can always do sync IPC calls to another process. The overhead is in the microseconds so it won't be noticeable. (Personally, I don't think this paper is evidence that we should move sqlite into a separate process, for similar reasons as to Scott.) PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Paper about DRAM error rates
On Tue, Oct 6, 2009 at 5:53 PM, John Abd-El-Malek j...@chromium.org wrote: If corruption in the in-memory URL database doesn't survive a crash (i.e. because it's recreated each time), It doesn't I'm not sure I understand why moving it to another process is unworkable? Chrome code is littered with many examples of how we turned synchronous operations into asynchronous ones. The user-visible behavior cannot be async. Inline autocomplete must never race the user's action or it goes from awesome to hellishly annoying and awful. But if worst comes to worst and we can't, you can always do sync IPC calls to another process. The overhead is in the microseconds so it won't be noticeable. I'd far prefer to keep it in the UI thread even if it were subject to these corruption issues. Doing sync IPC from the UI thread to a sqlite thread sounds like a recipe for Jank. PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Paper about DRAM error rates
On Tue, Oct 6, 2009 at 5:56 PM, Peter Kasting pkast...@google.com wrote: On Tue, Oct 6, 2009 at 5:53 PM, John Abd-El-Malek j...@chromium.orgwrote: If corruption in the in-memory URL database doesn't survive a crash (i.e. because it's recreated each time), It doesn't I'm not sure I understand why moving it to another process is unworkable? Chrome code is littered with many examples of how we turned synchronous operations into asynchronous ones. The user-visible behavior cannot be async. Inline autocomplete must never race the user's action or it goes from awesome to hellishly annoying and awful. But if worst comes to worst and we can't, you can always do sync IPC calls to another process. The overhead is in the microseconds so it won't be noticeable. I'd far prefer to keep it in the UI thread even if it were subject to these corruption issues. Doing sync IPC from the UI thread to a sqlite thread sounds like a recipe for Jank. Note, I don't know what the right answer for this specific case (I think more investigation is necessary), but I do want to point out that I don't think moving it to another process will introduce jank. If it's currently not done on the same thread as other databases, then if it were moved to another process, it would have to be done on a separate thread as well. Our overhead for sync IPCs is in the microseconds. Of course, actually implementing this and comparing histograms of in-process and out-of-process delays is the fool-proof way of proving this :) PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Paper about DRAM error rates
I am with the others that don't see move sqlite to another process as a natural outcome of these thread. If using more memory is the concern, another process uses more memory. sqlite is not crashing *that* much; yes it was the top crasher for a while but it was a data race --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Has anyone built successfully on Win7 64bit? I am getting bash.exe errors
Still having the same issue after following John's suggestions. Being forced to use a separate cygwin's bash.exe. On Oct 2, 12:16 am, Abubakar abubak...@gmail.com wrote: cygwin is supposed to be inside the chrome source that u download. Not to be done anything about it separately. On Fri, Oct 2, 2009 at 4:05 AM, Dan Kegel d...@kegel.com wrote: It's not supposed to be that way... maybe we need to check in a new cygwin. On Thu, Oct 1, 2009 at 4:03 PM, vha14 vuh...@gmail.com wrote: So it looks like I need to install Cygwin separately before I can build Chrome? If so this should be added to the Windows build instruction page. On Oct 1, 2:59 pm, Mohamed Mansour m...@chromium.org wrote: I run Cygwin Bash Shell not from Command Prompt: moha...@mohamed-pc ~$ bash -Mohamed On Thu, Oct 1, 2009 at 5:32 PM, vha14 vuh...@gmail.com wrote: Hi Mohamed, can you run bash.exe from cmd? I get the following error: E:\chromium\home\chrome-svn\tarball\chromium\src\third_party\cygwin \binbash 9 [main] bash 8384 _cygtls::handle_exceptions: Exception: STATUS_ACCESS_VIOLATION 9964 [main] bash 8384 open_stackdumpfile: Dumping stack trace to bash.exe.stackdump 211065 [main] bash 8384 _cygtls::handle_exceptions: Exception: STATUS_ACCESS_VIOLATION 229623 [main] bash 8384 _cygtls::handle_exceptions: Error while dumping state (probably corrupted stack) On Oct 1, 2:17 pm, Mohamed Mansour m...@chromium.org wrote: Windows 7 64bit works fine here (using the default settings from dev.chromium.org) Make sure you have access to the folder your writing to. Some folders require admin mode. -Mohamed On Thu, Oct 1, 2009 at 4:10 PM, vha14 vuh...@gmail.com wrote: Detailed error message: 1-- Build started: Project: js2c, Configuration: Debug Win32 -- 1js2c 2-- Build started: Project: cygwin, Configuration: Debug Win32 -- 2setup_mount 1 30 [main] bash 8980 _cygtls::handle_exceptions: Exception: STATUS_ACCESS_VIOLATION 1 3645 [main] bash 8980 open_stackdumpfile: Dumping stack trace to bash.exe.stackdump 2The operation completed successfully. 2The operation completed successfully. 1Project : error PRJ0002 : Error result 35584 returned from 'C: \Windows\SysWow64\cmd.exe'. Content of bash.exe.stackdump: E:\chromium\home\chrome-svn\tarball\chromium\src\chromemore bash.exe.stackdump Exception: STATUS_ACCESS_VIOLATION at eip=0043AE30 eax= ebx= ecx=61106EC8 edx= esi=611021A0 edi=0045A3E0 ebp=0028CBC8 esp=0028C58C program=e:\chromium\home\chrome-svn\tarball \chromium\s rc\third_party\cygwin\bin\bash.exe, pid 8296, thread main cs=0023 ds=002B es=002B fs=0053 gs=002B ss=002B Stack trace: Frame Function Args 0028CBC8 0043AE30 (0003, 02361C00, 02360090, 772F) 0028CD68 610060D8 (, 0028CDA0, 61005450, 0028CDA0) 61005450 61004416 (009C, A02404C7, E8611021, FF48) 431390 [main] bash 8296 _cygtls::handle_exceptions: Exception: STATUS_ACCESS_VI OLATION 509897 [main] bash 8296 _cygtls::handle_exceptions: Error while dumping state ( probably corrupted stack) --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Paper about DRAM error rates
This isn't about decreasing memory usage. It's about getting rid of nasty problems like the browser process crashing every startup because of a corrupt database and decreasing browser process crashes in general. I think it's fair that not everyone shares the same opinion, but I do hope that an experiment is run and we can compare numbers to see the effects on crash rates. If Chase or others do it, that's great, if not, I'll try to do it after the jank task force. On Tue, Oct 6, 2009 at 6:20 PM, cpu c...@chromium.org wrote: I am with the others that don't see move sqlite to another process as a natural outcome of these thread. If using more memory is the concern, another process uses more memory. sqlite is not crashing *that* much; yes it was the top crasher for a while but it was a data race --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Who owns crash...@chromium.org and why is there so many updates from it?
I got 21 emails in the last day for http://code.google.com/p/chromium/issues/detail?id=20915 --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Chrome Layout Tests Task Force status updates 10/6
Hello, Attached are the meeting notes from the most recent non-existent Layout Tests Task Force meeting. (Yes, that was a joke.) In lieu of meeting notes, here, once again, are the status updates from the intrepid members of the LTTF. tinyurl.com/LTTFstatus At last count, we are down to 627 failing tests (on Windows). Woo! cheers, Jeff --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~--- attachment: meeting-notes.png
[chromium-dev] Re: Who owns crash...@chromium.org and why is there so many updates from it?
maruel, I think he's working on decreasing that number. On Tue, Oct 6, 2009 at 6:51 PM, John Abd-El-Malek j...@chromium.org wrote: I got 21 emails in the last day for http://code.google.com/p/chromium/issues/detail?id=20915 --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Who owns crash...@chromium.org and why is there so many updates from it?
Oh sorry, I was thinking of buildbot@ On Tue, Oct 6, 2009 at 6:57 PM, Lei Zhang thes...@chromium.org wrote: maruel, I think he's working on decreasing that number. On Tue, Oct 6, 2009 at 6:51 PM, John Abd-El-Malek j...@chromium.org wrote: I got 21 emails in the last day for http://code.google.com/p/chromium/issues/detail?id=20915 --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] buildbot failure in Chromium on Linux Builder (ChromeOS), revision 28229
Automatically closing tree for compile on Linux Builder (ChromeOS) http://build.chromium.org/buildbot/waterfall/builders/Linux%20Builder%20%28ChromeOS%29/builds/4132 http://build.chromium.org/buildbot/waterfall/waterfall?builder=Linux%20Builder%20%28ChromeOS%29 --= Automatically closing tree for compile on Linux Builder (ChromeOS) =-- Revision: 28229 Blame list: rafa...@chromium.org Buildbot waterfall: http://build.chromium.org/ --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] buildbot failure in Chromium on Linux Perf, revision 0
Automatically closing tree for compile on Linux Perf http://build.chromium.org/buildbot/waterfall/builders/Linux%20Perf/builds/2843 http://build.chromium.org/buildbot/waterfall/waterfall?builder=Linux%20Perf --= Automatically closing tree for compile on Linux Perf =-- Revision: Blame list: Buildbot waterfall: http://build.chromium.org/ --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Who owns crash...@chromium.org and why is there so many updates from it?
On Tue, Oct 6, 2009 at 8:57 PM, Anthony LaForge lafo...@chromium.orgwrote: The short of it: - People manually associated bugs in http:crash - My tool creates its own map of signatures and for whatever reason that bug is on all of them - It goes through each aggregate signature and updates the status of the bug (which is a flash crasher) - It's made much worse because we are dealing w/ crashes that don't have symbols and cannot be aggregated... What went wrong: - The limiting function (seeing if crash-VERSION) was applied does not happen for priority updates. This was actually intentional since we start looking at crash data early on. However this should no longer be needed since we wait for enough data that priority should no longer be shifting. What can be done about it? - I will put a limiter on setting the priority Thanks. Kind Regards, Anthony Laforge Technical Program Manager Mountain View, CA On Tue, Oct 6, 2009 at 8:46 PM, Patrick Johnson patr...@chromium.orgwrote: John's question is about why it's generating so many issue updates. Patrick On Tue, Oct 6, 2009 at 8:41 PM, Anthony LaForge lafo...@chromium.org wrote: It's the role account that manages crashes and crash related bugs. Kind Regards, Anthony Laforge Technical Program Manager Mountain View, CA On Tue, Oct 6, 2009 at 7:26 PM, Patrick Johnson patr...@chromium.org wrote: [+laforge] On Tue, Oct 6, 2009 at 6:51 PM, John Abd-El-Malek j...@chromium.org wrote: I got 21 emails in the last day for http://code.google.com/p/chromium/issues/detail?id=20915 --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: How to deal with flaky unit tests
On Wed, Oct 7, 2009 at 02:02, Nicolas Sylvain nsylv...@chromium.org wrote: Once we start tagging the flaky tests, we will monitor the flakiness dashboard and make sure that a test that is no longer flaky has its FLAKY_ tag removed. It may be a good idea to expand the number of tests listed in the flakiness report from Top15 to Top20 or maybe even Top30... sometimes a test becomes only a bit less flaky, just enough to not appear in Top15. On the other hand, we have a lot of resource-related test failures (I don't know too much how Visual Studio's build system works - especially with gyp, but maybe someone will manage to investigate and fix that). This is not the fault of the test, just a bug in the build system. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Paper about DRAM error rates
On Tue, Oct 6, 2009 at 6:49 PM, John Abd-El-Malek j...@chromium.org wrote: This isn't about decreasing memory usage. It's about getting rid of nasty problems like the browser process crashing every startup because of a corrupt database and decreasing browser process crashes in general. I think it's fair that not everyone shares the same opinion, but I do hope that an experiment is run and we can compare numbers to see the effects on crash rates. If Chase or others do it, that's great, if not, I'll try to do it after the jank task force. Didn't find another bug on file for this already so I filed crbug.com/24061. Chase On Tue, Oct 6, 2009 at 6:20 PM, cpu c...@chromium.org wrote: I am with the others that don't see move sqlite to another process as a natural outcome of these thread. If using more memory is the concern, another process uses more memory. sqlite is not crashing *that* much; yes it was the top crasher for a while but it was a data race --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: How to deal with flaky unit tests
If a test sometimes crashes or hangs, it'll still be disabled, right?-darin On Tue, Oct 6, 2009 at 5:02 PM, Nicolas Sylvain nsylv...@chromium.orgwrote: Hello, We currently have more than 50 unit tests that are disabled. Most of them because they were flaky. Disabling tests is bad because we lose complete coverage on them, so I implemented a way to mark tests as flaky. The same way you disable a test with DISABLED_ at the beginning of its name, you can now mark is as flaky with FLAKY_. The behavior is exactly the same as any other running tests. You will still be able to see when it fails (and why). The only difference is that if only FLAKY_ tests failed, the buildbot/trybots won't consider it as a failure. On the waterfall, it will show the box as orange with the list of all flaky tests that failed (pending one more buildbot restart). On the console view it will stay green. But.. this is not a toy. Flaky tests are bad. We should mark tests flaky only if we really have to, and if you do, please make sure to file a P1 bug. Set the owner of the bug to whoever regressed the test. If you can't find who regressed the test, assign it to the person who originally wrote the test. Once we start tagging the flaky tests, we will monitor the flakiness dashboard and make sure that a test that is no longer flaky has its FLAKY_ tag removed. Let me know if you have questions. Thanks Nicolas --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
