Package Details: chromium-dev 126.0.6423.2-1

Git Clone URL: https://aur.archlinux.org/chromium-dev.git (read-only, click to copy)
Package Base: chromium-dev
Description: The open-source project behind Google Chrome (Dev Channel)
Upstream URL: http://www.chromium.org
Keywords: browser web
Licenses: BSD
Submitter: None
Maintainer: sl1pkn07
Last Packager: sl1pkn07
Votes: 160
Popularity: 0.010897
First Submitted: 2010-05-17 09:04 (UTC)
Last Updated: 2024-04-21 19:18 (UTC)

Dependencies (84)

Required by (0)

Sources (13)

Latest Comments

« First ‹ Previous 1 .. 100 101 102 103 104 105 106 107 108 109 110 .. 152 Next › Last »

misc commented on 2012-05-01 19:09 (UTC)

Forgot that patch files can be used to revert them, too ("-R" instead of "-N"). :) So I just tested 50-svn with said patch reverted, and indeed it crashed again. Which also means that if 50-svn or a patched 49.1.1 still crashes for you, it's a different bug — in which case you should of course submit your own ticket.

misc commented on 2012-05-01 18:58 (UTC)

> Do you think that a recompile of chromium against the new ICU would help? It should not; if Chromium links dynamically to ICU (check with eg "ldd /usr/lib/chromium-dev/chromium | grep libicu" — I get three links to /usr/lib/libicu[…].so.50, whereas you'd get *.49, of course) all that patch ought to have changed would be some of those files in /usr/lib. > would this prevent the patched ICU from being used by chromium? Indeed it does. I'm afraid that if you have not changed back "use_system_icu=0" to 1 and removed that above "\! -path 'third_party/icu/*' \" line, your Chromium compiles most likely linked to the ICU version shipped with the Chromium tarball (some past version, 4.5 or so I think). Just use ldd again to check — those three links would probably not show at all in that case, or perhaps be a self-reference to chromium itself.

wuffleton commented on 2012-05-01 17:33 (UTC)

@misc: That patch applied cleanly to 49.1.1's source and the compile was successful, however, I can still replicate the crash in the 20.0.1120.0 package I built earlier. Do you think that a recompile of chromium against the new ICU would help? (Also, I noticed that the PKGBUILD configures chromium to not use the system's ICU, would this prevent the patched ICU from being used by chromium?)

misc commented on 2012-05-01 16:48 (UTC)

pedberg suggests that the following fix is what solved the crashes for me with ICU 50-svn, and could readily be applied to 49.1.1 as well: http://pastebin.com/raw.php?i=FyTd1ea4 Just add it as eg "patch -Np1 -i <path>" before ./configure in build() of ICU's PKGBUILD. If Chromium has been compiled with 49.1.1 then there should be no need to recompile it — or the other packages — to test (just close the programs or better restart, of course).

wuffleton commented on 2012-04-30 08:02 (UTC)

Looks like it was just stubborn with its crashes before. I'm experiencing the exact same issues as before with the normal build.

wuffleton commented on 2012-04-30 03:32 (UTC)

Derp. I just realized that leaving Ccache enabled while bug testing is a terrible idea. I built icu-49.1.1-1 and chromium-dev 20.0.1120.0 with debug symbols and ccache disabled with the intent of getting valgrind/gdb traces, however I can't reproduce the crash anymore. I was unable to get GDB to start chromium, but the crash I was able to cause through valgrind doesn't look related. (I was using a script to spam the omnibox rather than just typing random stuff into it as I did before. Here's my trace if anyone else can make sense of it: http://pastebin.com/0REr7xRX ) I'm going to try clearing CCache and compiling the normal version of chromium-dev to confirm that it doesn't exhibit the bug under normal use.

misc commented on 2012-04-29 17:04 (UTC)

The crashes of ICU 49.1.1 are indeed gone for me with ICU 50-svn (C20.0.1122.0). Note that if you install the latter you'll also have to recompile all packages that depend on it for those (and those that in turn depend on them, etc.) to work again. Again, additional valgrind & gdb traces will help to locate and properly fix the bug(s?).

misc commented on 2012-04-29 13:20 (UTC)

@DarkSniper: Thanks for testing. Maybe it's an ICU 49 bug then, after all — I'll test it again next time. @all: There's a ticket for it on ICU's bugtracker; the dev has asked for valgrind traces with ICU compiled for debug (see eg the Arch Wiki page "Debug - Getting Traces" for instructions): http://bugs.icu-project.org/trac/ticket/9276

wuffleton commented on 2012-04-29 04:39 (UTC)

@misc: I've compiled version 20.0.1120.0 against those package versions and it still experiences the same segfault as before on my end.

« First ‹ Previous 1 .. 100 101 102 103 104 105 106 107 108 109 110 .. 152 Next › Last »