* getrlimit failed (chromium on musl) @ 2017-01-18 14:08 Alba Pompeo 2017-01-18 14:18 ` Rich Felker 2017-01-18 15:51 ` Samuel Holland 0 siblings, 2 replies; 13+ messages in thread From: Alba Pompeo @ 2017-01-18 14:08 UTC (permalink / raw) To: musl Hi. Running chromium on a musl system spams this message. getrlimit(RLIMIT_NOFILE) failed Any idea how to figure out what's wrong? Thanks. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: getrlimit failed (chromium on musl) 2017-01-18 14:08 getrlimit failed (chromium on musl) Alba Pompeo @ 2017-01-18 14:18 ` Rich Felker 2017-01-18 15:18 ` Alba Pompeo 2017-01-18 15:51 ` Samuel Holland 1 sibling, 1 reply; 13+ messages in thread From: Rich Felker @ 2017-01-18 14:18 UTC (permalink / raw) To: musl On Wed, Jan 18, 2017 at 12:08:55PM -0200, Alba Pompeo wrote: > Hi. > > Running chromium on a musl system spams this message. > > getrlimit(RLIMIT_NOFILE) failed > > Any idea how to figure out what's wrong? strace would be the best way to debug this, I think. My guess is that chrome's seccomp sandbox wrongly blocks one or more syscalls needed in getrlimit. Rich ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: getrlimit failed (chromium on musl) 2017-01-18 14:18 ` Rich Felker @ 2017-01-18 15:18 ` Alba Pompeo 2017-01-18 15:56 ` Rich Felker 0 siblings, 1 reply; 13+ messages in thread From: Alba Pompeo @ 2017-01-18 15:18 UTC (permalink / raw) To: musl Does it help? http://sprunge.us/iWdT On Wed, Jan 18, 2017 at 12:18 PM, Rich Felker <dalias@libc.org> wrote: > On Wed, Jan 18, 2017 at 12:08:55PM -0200, Alba Pompeo wrote: >> Hi. >> >> Running chromium on a musl system spams this message. >> >> getrlimit(RLIMIT_NOFILE) failed >> >> Any idea how to figure out what's wrong? > > strace would be the best way to debug this, I think. My guess is that > chrome's seccomp sandbox wrongly blocks one or more syscalls needed in > getrlimit. > > Rich ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: getrlimit failed (chromium on musl) 2017-01-18 15:18 ` Alba Pompeo @ 2017-01-18 15:56 ` Rich Felker 0 siblings, 0 replies; 13+ messages in thread From: Rich Felker @ 2017-01-18 15:56 UTC (permalink / raw) To: musl On Wed, Jan 18, 2017 at 01:18:34PM -0200, Alba Pompeo wrote: > Does it help? http://sprunge.us/iWdT No because it seems to be tracing only the main process/thread not the one printing the error. You need the -f option to follow forks/clones. Rich > On Wed, Jan 18, 2017 at 12:18 PM, Rich Felker <dalias@libc.org> wrote: > > On Wed, Jan 18, 2017 at 12:08:55PM -0200, Alba Pompeo wrote: > >> Hi. > >> > >> Running chromium on a musl system spams this message. > >> > >> getrlimit(RLIMIT_NOFILE) failed > >> > >> Any idea how to figure out what's wrong? > > > > strace would be the best way to debug this, I think. My guess is that > > chrome's seccomp sandbox wrongly blocks one or more syscalls needed in > > getrlimit. > > > > Rich ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: getrlimit failed (chromium on musl) 2017-01-18 14:08 getrlimit failed (chromium on musl) Alba Pompeo 2017-01-18 14:18 ` Rich Felker @ 2017-01-18 15:51 ` Samuel Holland 2017-01-18 16:13 ` Alba Pompeo 1 sibling, 1 reply; 13+ messages in thread From: Samuel Holland @ 2017-01-18 15:51 UTC (permalink / raw) To: musl On 01/18/17 08:08, Alba Pompeo wrote: > Hi. > > Running chromium on a musl system spams this message. > > getrlimit(RLIMIT_NOFILE) failed > > Any idea how to figure out what's wrong? The problem is that the sandbox blocks prlimit64 with EPERM, but musl only falls back to getrlimit on ENOSYS. The diff below will fix the error. From the linked bug, the only reason it is blocked in the first place is ChromeOS, and this change should be fine even there. --- chromium-55.0.2883.75/content/common/sandbox_linux/bpf_renderer_policy_linux.cc.orig +++ chromium-55.0.2883.75/content/common/sandbox_linux/bpf_renderer_policy_linux.cc @@ -88,7 +88,7 @@ ResultExpr RendererProcessPolicy::EvaluateSyscall(int sysno) const { case __NR_sched_setscheduler: return sandbox::RestrictSchedTarget(GetPolicyPid(), sysno); case __NR_prlimit64: - return Error(EPERM); // See crbug.com/160157. + return Error(ENOSYS); // See crbug.com/160157. default: // Default on the content baseline policy. return SandboxBPFBasePolicy::EvaluateSyscall(sysno); > Thanks. Regards, Samuel ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: getrlimit failed (chromium on musl) 2017-01-18 15:51 ` Samuel Holland @ 2017-01-18 16:13 ` Alba Pompeo 2017-01-27 0:41 ` Alba Pompeo 0 siblings, 1 reply; 13+ messages in thread From: Alba Pompeo @ 2017-01-18 16:13 UTC (permalink / raw) To: musl Ran strace -f. [pid 13354] prlimit64(0, RLIMIT_NOFILE, NULL, {rlim_cur=1024, rlim_max=4*1024}) = 0 [pid 13350] clone(child_stack=NULL, flags=CLONE_NEWUSER|SIGCHLD) = -1 EPERM (Operation not permitted) [pid 13354] clone(child_stack=NULL, flags=CLONE_NEWPID|CLONE_NEWNET|SIGCHLD) = -1 EPERM (Operation not permitted) [pid 13354] writev(2, [{iov_base=" but failed: errno = Operation n"..., iov_len=45}, {iov_base=NULL, iov_len=0}], 2 but failed: errno = Operation not permitted So the patch from Samuel should be a real solution. Thanks. On Wed, Jan 18, 2017 at 1:51 PM, Samuel Holland <samuel@sholland.org> wrote: > On 01/18/17 08:08, Alba Pompeo wrote: >> >> Hi. >> >> Running chromium on a musl system spams this message. >> >> getrlimit(RLIMIT_NOFILE) failed >> >> Any idea how to figure out what's wrong? > > > The problem is that the sandbox blocks prlimit64 with EPERM, but musl > only falls back to getrlimit on ENOSYS. The diff below will fix the > error. From the linked bug, the only reason it is blocked in the first > place is ChromeOS, and this change should be fine even there. > > --- > chromium-55.0.2883.75/content/common/sandbox_linux/bpf_renderer_policy_linux.cc.orig > +++ > chromium-55.0.2883.75/content/common/sandbox_linux/bpf_renderer_policy_linux.cc > @@ -88,7 +88,7 @@ ResultExpr RendererProcessPolicy::EvaluateSyscall(int > sysno) const { > case __NR_sched_setscheduler: > return sandbox::RestrictSchedTarget(GetPolicyPid(), sysno); > case __NR_prlimit64: > - return Error(EPERM); // See crbug.com/160157. > + return Error(ENOSYS); // See crbug.com/160157. > default: > // Default on the content baseline policy. > return SandboxBPFBasePolicy::EvaluateSyscall(sysno); > >> Thanks. > > > Regards, > Samuel > ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: getrlimit failed (chromium on musl) 2017-01-18 16:13 ` Alba Pompeo @ 2017-01-27 0:41 ` Alba Pompeo 2017-01-28 6:00 ` He X 2017-01-29 23:13 ` Samuel Holland 0 siblings, 2 replies; 13+ messages in thread From: Alba Pompeo @ 2017-01-27 0:41 UTC (permalink / raw) To: musl The patch worked. Many thanks Samuel. I hope they fix it upstream too for the future. Sadly Chromium still needs some patches to compile and work on musl. On Wed, Jan 18, 2017 at 2:13 PM, Alba Pompeo <albapompeo@gmail.com> wrote: > Ran strace -f. > > [pid 13354] prlimit64(0, RLIMIT_NOFILE, NULL, {rlim_cur=1024, > rlim_max=4*1024}) = 0 > [pid 13350] clone(child_stack=NULL, flags=CLONE_NEWUSER|SIGCHLD) = -1 > EPERM (Operation not permitted) > [pid 13354] clone(child_stack=NULL, > flags=CLONE_NEWPID|CLONE_NEWNET|SIGCHLD) = -1 EPERM (Operation not > permitted) > [pid 13354] writev(2, [{iov_base=" but failed: errno = Operation > n"..., iov_len=45}, {iov_base=NULL, iov_len=0}], 2 but failed: errno = > Operation not permitted > > So the patch from Samuel should be a real solution. > > Thanks. > > > > On Wed, Jan 18, 2017 at 1:51 PM, Samuel Holland <samuel@sholland.org> wrote: >> On 01/18/17 08:08, Alba Pompeo wrote: >>> >>> Hi. >>> >>> Running chromium on a musl system spams this message. >>> >>> getrlimit(RLIMIT_NOFILE) failed >>> >>> Any idea how to figure out what's wrong? >> >> >> The problem is that the sandbox blocks prlimit64 with EPERM, but musl >> only falls back to getrlimit on ENOSYS. The diff below will fix the >> error. From the linked bug, the only reason it is blocked in the first >> place is ChromeOS, and this change should be fine even there. >> >> --- >> chromium-55.0.2883.75/content/common/sandbox_linux/bpf_renderer_policy_linux.cc.orig >> +++ >> chromium-55.0.2883.75/content/common/sandbox_linux/bpf_renderer_policy_linux.cc >> @@ -88,7 +88,7 @@ ResultExpr RendererProcessPolicy::EvaluateSyscall(int >> sysno) const { >> case __NR_sched_setscheduler: >> return sandbox::RestrictSchedTarget(GetPolicyPid(), sysno); >> case __NR_prlimit64: >> - return Error(EPERM); // See crbug.com/160157. >> + return Error(ENOSYS); // See crbug.com/160157. >> default: >> // Default on the content baseline policy. >> return SandboxBPFBasePolicy::EvaluateSyscall(sysno); >> >>> Thanks. >> >> >> Regards, >> Samuel >> ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: getrlimit failed (chromium on musl) 2017-01-27 0:41 ` Alba Pompeo @ 2017-01-28 6:00 ` He X 2017-01-28 13:14 ` Szabolcs Nagy 2017-01-28 19:45 ` Samuel Holland 2017-01-29 23:13 ` Samuel Holland 1 sibling, 2 replies; 13+ messages in thread From: He X @ 2017-01-28 6:00 UTC (permalink / raw) To: musl [-- Attachment #1: Type: text/plain, Size: 3483 bytes --] After patched, chromium segfault three times in two days, e.g. when i try to upload a file in a baiduyun, crash when i click the upload button, and suddenly crashed twice, when --disable-sandbox, no crashing: [65422.256448] chromium[12257]: segfault at 3c1 ip 00007f69e30e075c sp 00007ffe5442efc0 error 4 in libc.so[7f69e30b9000+a1000] strace output(should be this one): 13:52:37.479810 prlimit64(0, RLIMIT_NOFILE, {rlim_cur=4*1024, rlim_max=4*1024}, NULL) = 0 13:52:37.479835 futex(0x7f98cbc02b6c, FUTEX_WAKE_PRIVATE, 1) = 1 13:52:37.479862 futex(0x7f98cbc02b4c, FUTEX_WAIT_PRIVATE, 4294967295, NULL) = 0 13:52:37.479961 rt_sigreturn({mask=[]}) = 61 13:52:37.479982 wait4(29341, NULL, 0, NULL) = ? ERESTARTSYS (To be restarted if SA_RESTART is set) 13:52:37.851264 wait4(29341, NULL, 0, NULL) = ? ERESTARTSYS (To be restarted if SA_RESTART is set) 13:52:42.127096 wait4(29341, NULL, 0, NULL) = ? ERESTARTSYS (To be restarted if SA_RESTART is set) 13:53:23.970709 wait4(29341, <unfinished ...>) = ? 13:53:30.693847 +++ killed by SIGSEGV +++ This patch is a bit dangerous, though it indeed solved the problem, i think EPERM is needed. Modifying musl is a better way, but is that correct? 2017-01-27 8:41 GMT+08:00 Alba Pompeo <albapompeo@gmail.com>: > The patch worked. > Many thanks Samuel. > I hope they fix it upstream too for the future. > Sadly Chromium still needs some patches to compile and work on musl. > > > > On Wed, Jan 18, 2017 at 2:13 PM, Alba Pompeo <albapompeo@gmail.com> wrote: > > Ran strace -f. > > > > [pid 13354] prlimit64(0, RLIMIT_NOFILE, NULL, {rlim_cur=1024, > > rlim_max=4*1024}) = 0 > > [pid 13350] clone(child_stack=NULL, flags=CLONE_NEWUSER|SIGCHLD) = -1 > > EPERM (Operation not permitted) > > [pid 13354] clone(child_stack=NULL, > > flags=CLONE_NEWPID|CLONE_NEWNET|SIGCHLD) = -1 EPERM (Operation not > > permitted) > > [pid 13354] writev(2, [{iov_base=" but failed: errno = Operation > > n"..., iov_len=45}, {iov_base=NULL, iov_len=0}], 2 but failed: errno = > > Operation not permitted > > > > So the patch from Samuel should be a real solution. > > > > Thanks. > > > > > > > > On Wed, Jan 18, 2017 at 1:51 PM, Samuel Holland <samuel@sholland.org> > wrote: > >> On 01/18/17 08:08, Alba Pompeo wrote: > >>> > >>> Hi. > >>> > >>> Running chromium on a musl system spams this message. > >>> > >>> getrlimit(RLIMIT_NOFILE) failed > >>> > >>> Any idea how to figure out what's wrong? > >> > >> > >> The problem is that the sandbox blocks prlimit64 with EPERM, but musl > >> only falls back to getrlimit on ENOSYS. The diff below will fix the > >> error. From the linked bug, the only reason it is blocked in the first > >> place is ChromeOS, and this change should be fine even there. > >> > >> --- > >> chromium-55.0.2883.75/content/common/sandbox_linux/bpf_ > renderer_policy_linux.cc.orig > >> +++ > >> chromium-55.0.2883.75/content/common/sandbox_linux/bpf_ > renderer_policy_linux.cc > >> @@ -88,7 +88,7 @@ ResultExpr RendererProcessPolicy::EvaluateSyscall(int > >> sysno) const { > >> case __NR_sched_setscheduler: > >> return sandbox::RestrictSchedTarget(GetPolicyPid(), sysno); > >> case __NR_prlimit64: > >> - return Error(EPERM); // See crbug.com/160157. > >> + return Error(ENOSYS); // See crbug.com/160157. > >> default: > >> // Default on the content baseline policy. > >> return SandboxBPFBasePolicy::EvaluateSyscall(sysno); > >> > >>> Thanks. > >> > >> > >> Regards, > >> Samuel > >> > [-- Attachment #2: Type: text/html, Size: 4780 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: getrlimit failed (chromium on musl) 2017-01-28 6:00 ` He X @ 2017-01-28 13:14 ` Szabolcs Nagy 2017-01-28 19:45 ` Samuel Holland 1 sibling, 0 replies; 13+ messages in thread From: Szabolcs Nagy @ 2017-01-28 13:14 UTC (permalink / raw) To: musl * He X <xw897002528@gmail.com> [2017-01-28 14:00:59 +0800]: > After patched, chromium segfault three times in two days, e.g. when i try > to upload a file in a baiduyun, crash when i click the upload button, and > suddenly crashed twice, when --disable-sandbox, no crashing: > [65422.256448] chromium[12257]: segfault at 3c1 ip 00007f69e30e075c sp > 00007ffe5442efc0 error 4 in libc.so[7f69e30b9000+a1000] > can you provide your libc.so binary? or at least objdump around address 0x00007f69e30e075c - 0x7f69e30b9000 = 0x2775c objdump -rdw libc.so |grep -C 100 '2775c:' make the context (-C) large enough so we see the function entry, a proper backtrace would be useful too (e.g. looking at the coredump from gdb). > This patch is a bit dangerous, though it indeed solved the problem, i think > EPERM is needed. Modifying musl is a better way, but is that correct? disabling syscalls with EPERM is a chrome bug, but this issue seems independent. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: getrlimit failed (chromium on musl) 2017-01-28 6:00 ` He X 2017-01-28 13:14 ` Szabolcs Nagy @ 2017-01-28 19:45 ` Samuel Holland 2017-01-28 20:59 ` Rich Felker 1 sibling, 1 reply; 13+ messages in thread From: Samuel Holland @ 2017-01-28 19:45 UTC (permalink / raw) To: musl Hello, On 01/28/17 00:00, He X wrote: > After patched, chromium segfault three times in two days, e.g. when > i try to upload a file in a baiduyun, crash when i click the upload > button, and suddenly crashed twice, when --disable-sandbox, no > crashing: [65422.256448] chromium[12257]: segfault at 3c1 ip > 00007f69e30e075c sp 00007ffe5442efc0 error 4 in > libc.so[7f69e30b9000+a1000] I have had zero crashes with chromium and this patch (over more than a month of use). > strace output(should be this one): > 13:52:37.479810 prlimit64(0, RLIMIT_NOFILE, {rlim_cur=4*1024, > rlim_max=4*1024}, NULL) = 0 > 13:52:37.479835 futex(0x7f98cbc02b6c, FUTEX_WAKE_PRIVATE, 1) = 1 > 13:52:37.479862 futex(0x7f98cbc02b4c, FUTEX_WAIT_PRIVATE, 4294967295, > NULL) = 0 > 13:52:37.479961 rt_sigreturn({mask=[]}) = 61 > 13:52:37.479982 wait4(29341, NULL, 0, NULL) = ? ERESTARTSYS (To be > restarted if SA_RESTART is set) > 13:52:37.851264 wait4(29341, NULL, 0, NULL) = ? ERESTARTSYS (To be > restarted if SA_RESTART is set) > 13:52:42.127096 wait4(29341, NULL, 0, NULL) = ? ERESTARTSYS (To be > restarted if SA_RESTART is set) > 13:53:23.970709 wait4(29341, <unfinished ...>) = ? > 13:53:30.693847 +++ killed by SIGSEGV +++ Given the 53 seconds between the prlimit64 call and the crash, I doubt they are related. Regards, Samuel ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: getrlimit failed (chromium on musl) 2017-01-28 19:45 ` Samuel Holland @ 2017-01-28 20:59 ` Rich Felker 2017-01-29 4:54 ` He X 0 siblings, 1 reply; 13+ messages in thread From: Rich Felker @ 2017-01-28 20:59 UTC (permalink / raw) To: musl On Sat, Jan 28, 2017 at 01:45:25PM -0600, Samuel Holland wrote: > Hello, > > On 01/28/17 00:00, He X wrote: > >After patched, chromium segfault three times in two days, e.g. when > >i try to upload a file in a baiduyun, crash when i click the upload > >button, and suddenly crashed twice, when --disable-sandbox, no > >crashing: [65422.256448] chromium[12257]: segfault at 3c1 ip > >00007f69e30e075c sp 00007ffe5442efc0 error 4 in > >libc.so[7f69e30b9000+a1000] > > I have had zero crashes with chromium and this patch (over more than a > month of use). > > >strace output(should be this one): > >13:52:37.479810 prlimit64(0, RLIMIT_NOFILE, {rlim_cur=4*1024, > >rlim_max=4*1024}, NULL) = 0 > >13:52:37.479835 futex(0x7f98cbc02b6c, FUTEX_WAKE_PRIVATE, 1) = 1 > >13:52:37.479862 futex(0x7f98cbc02b4c, FUTEX_WAIT_PRIVATE, 4294967295, > >NULL) = 0 > >13:52:37.479961 rt_sigreturn({mask=[]}) = 61 > >13:52:37.479982 wait4(29341, NULL, 0, NULL) = ? ERESTARTSYS (To be > >restarted if SA_RESTART is set) > >13:52:37.851264 wait4(29341, NULL, 0, NULL) = ? ERESTARTSYS (To be > >restarted if SA_RESTART is set) > >13:52:42.127096 wait4(29341, NULL, 0, NULL) = ? ERESTARTSYS (To be > >restarted if SA_RESTART is set) > >13:53:23.970709 wait4(29341, <unfinished ...>) = ? > >13:53:30.693847 +++ killed by SIGSEGV +++ > > Given the 53 seconds between the prlimit64 call and the crash, I doubt > they are related. Agreed. But there does seem to be something else causing musl-linked chromium to crash [more often] when sandbox is enabled. I suspect there's something else they're doing wrong with seccomp that's breaking it. This strace seems to be done without -f, making it mostly useless. Rich ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: getrlimit failed (chromium on musl) 2017-01-28 20:59 ` Rich Felker @ 2017-01-29 4:54 ` He X 0 siblings, 0 replies; 13+ messages in thread From: He X @ 2017-01-29 4:54 UTC (permalink / raw) To: musl [-- Attachment #1: Type: text/plain, Size: 1947 bytes --] guys, i cleared, this is another bug about intl, check my another mail: http://www.openwall.com/lists/musl/2017/01/29/1 2017-01-29 4:59 GMT+08:00 Rich Felker <dalias@libc.org>: > On Sat, Jan 28, 2017 at 01:45:25PM -0600, Samuel Holland wrote: > > Hello, > > > > On 01/28/17 00:00, He X wrote: > > >After patched, chromium segfault three times in two days, e.g. when > > >i try to upload a file in a baiduyun, crash when i click the upload > > >button, and suddenly crashed twice, when --disable-sandbox, no > > >crashing: [65422.256448] chromium[12257]: segfault at 3c1 ip > > >00007f69e30e075c sp 00007ffe5442efc0 error 4 in > > >libc.so[7f69e30b9000+a1000] > > > > I have had zero crashes with chromium and this patch (over more than a > > month of use). > > > > >strace output(should be this one): > > >13:52:37.479810 prlimit64(0, RLIMIT_NOFILE, {rlim_cur=4*1024, > > >rlim_max=4*1024}, NULL) = 0 > > >13:52:37.479835 futex(0x7f98cbc02b6c, FUTEX_WAKE_PRIVATE, 1) = 1 > > >13:52:37.479862 futex(0x7f98cbc02b4c, FUTEX_WAIT_PRIVATE, 4294967295, > > >NULL) = 0 > > >13:52:37.479961 rt_sigreturn({mask=[]}) = 61 > > >13:52:37.479982 wait4(29341, NULL, 0, NULL) = ? ERESTARTSYS (To be > > >restarted if SA_RESTART is set) > > >13:52:37.851264 wait4(29341, NULL, 0, NULL) = ? ERESTARTSYS (To be > > >restarted if SA_RESTART is set) > > >13:52:42.127096 wait4(29341, NULL, 0, NULL) = ? ERESTARTSYS (To be > > >restarted if SA_RESTART is set) > > >13:53:23.970709 wait4(29341, <unfinished ...>) = ? > > >13:53:30.693847 +++ killed by SIGSEGV +++ > > > > Given the 53 seconds between the prlimit64 call and the crash, I doubt > > they are related. > > Agreed. But there does seem to be something else causing musl-linked > chromium to crash [more often] when sandbox is enabled. I suspect > there's something else they're doing wrong with seccomp that's > breaking it. This strace seems to be done without -f, making it mostly > useless. > > Rich > [-- Attachment #2: Type: text/html, Size: 2701 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: getrlimit failed (chromium on musl) 2017-01-27 0:41 ` Alba Pompeo 2017-01-28 6:00 ` He X @ 2017-01-29 23:13 ` Samuel Holland 1 sibling, 0 replies; 13+ messages in thread From: Samuel Holland @ 2017-01-29 23:13 UTC (permalink / raw) To: musl, Alba Pompeo Hello, On 01/26/17 18:41, Alba Pompeo wrote: > The patch worked. > Many thanks Samuel. > I hope they fix it upstream too for the future. > Sadly Chromium still needs some patches to compile and work on musl. Forward-porting my patches to chromium 56, I see that this has already been fixed upstream: https://bugs.chromium.org/p/chromium/issues/detail?id=662450 Regards, Samuel ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2017-01-29 23:13 UTC | newest] Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-01-18 14:08 getrlimit failed (chromium on musl) Alba Pompeo 2017-01-18 14:18 ` Rich Felker 2017-01-18 15:18 ` Alba Pompeo 2017-01-18 15:56 ` Rich Felker 2017-01-18 15:51 ` Samuel Holland 2017-01-18 16:13 ` Alba Pompeo 2017-01-27 0:41 ` Alba Pompeo 2017-01-28 6:00 ` He X 2017-01-28 13:14 ` Szabolcs Nagy 2017-01-28 19:45 ` Samuel Holland 2017-01-28 20:59 ` Rich Felker 2017-01-29 4:54 ` He X 2017-01-29 23:13 ` Samuel Holland
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/musl/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).