#ruby-core on 2013-04-21 — irc logs at freenode.irclog.whitequark.org

2013-03-25 00:43 hsbt_away changed the topic of #ruby-core to: check the latest release candidate for 1.9.1 release ftp.ruby-lang.org:/home/yugui/ruby-1.9.1-r26021+1.tar.bz2

00:23 idkazuma has joined #ruby-core

00:54 nurse has joined #ruby-core

01:06 idkazuma has quit [Remote host closed the connection]

01:20 idkazuma has joined #ruby-core

01:53 nurse has quit [Ping timeout: 264 seconds]

01:53 idkazuma has quit [Remote host closed the connection]

02:07 nurse has joined #ruby-core

02:11 nurse has quit [Client Quit]

02:14 nurse has joined #ruby-core

04:34 agarie has joined #ruby-core

05:17 shiba1 has joined #ruby-core

05:31 shiba1 has quit [Quit: Leaving.]

05:43 charliesome has joined #ruby-core

05:56 agarie has quit [Ping timeout: 276 seconds]

05:56 nari has joined #ruby-core

06:01 agarie has joined #ruby-core

06:16 shiba___ has joined #ruby-core

06:26 agarie_ has joined #ruby-core

06:26 agarie_ has quit [Client Quit]

06:30 agarie has quit [Ping timeout: 276 seconds]

06:45 idkazuma has joined #ruby-core

07:16 nari has quit [Ping timeout: 240 seconds]

07:19 idkazuma has quit [Remote host closed the connection]

07:29 nari has joined #ruby-core

08:12 shiba___ has quit [Ping timeout: 258 seconds]

08:26 nari has quit [Ping timeout: 258 seconds]

08:29 shiba___ has joined #ruby-core

08:44 idkazuma has joined #ruby-core

09:36 shiba___ has quit [Ping timeout: 252 seconds]

10:05 <znz_jp> biff: [ruby-changes:28349] hsbt:r40401 (trunk): Replace use of obsolete variable `last-command-char` by @maser [fix GH-290] - http://mla.n-z.jp/?ruby-changes=28349

10:24 travis-ci has joined #ruby-core

10:24 <travis-ci> [travis-ci] The build was broken. by @hsbt: See http://travis-ci.org/ruby/ruby/builds/6510246

10:24 travis-ci has left #ruby-core [#ruby-core]

10:38 <charliesome> _ko1: are you there?

10:47 judofyr has joined #ruby-core

10:55 idkazuma has quit [Remote host closed the connection]

10:57 idkazuma has joined #ruby-core

11:07 judofyr has quit [Remote host closed the connection]

11:45 idkazuma has quit [Remote host closed the connection]

11:52 idkazuma has joined #ruby-core

12:35 <znz_jp> biff: [ruby-changes:28350] charliesome:r40402 (trunk): * configure.in: Use sigsetjmp by default so jumping out of signal - http://mla.n-z.jp/?ruby-changes=28350

12:49 idkazuma has quit [Remote host closed the connection]

12:53 travis-ci has joined #ruby-core

12:53 <travis-ci> [travis-ci] The build was fixed. by @charliesome: See http://travis-ci.org/ruby/ruby/builds/6512266

12:53 travis-ci has left #ruby-core [#ruby-core]

13:08 nagachika has joined #ruby-core

13:16 rafaelfranca has quit [Read error: Connection reset by peer]

13:16 rafaelfranca has joined #ruby-core

13:38 shiba___ has joined #ruby-core

13:45 shiba___ has quit [Ping timeout: 246 seconds]

13:49 <_ko1> hi

13:49 <_ko1> charliesome?

13:49 <charliesome> hi _ko1

13:49 <_ko1> hi

13:50 <_ko1> i have a question about http://svn.ruby-lang.org/cgi-bin/viewvc.cgi?revision=40402&view=revision

13:50 <charliesome> _ko1: that's what i wanted to talk about too

13:50 <charliesome> _ko1: you go first

13:50 <_ko1> use sigsetjmp instead of all of setjmp?

13:50 <_ko1> sigsetjmp is slower than setjmp, so i had replaced them

13:50 <charliesome> _ko1: interesting

13:50 <_ko1> (old ruby 1.8 uses sigsetjmp everywhere)

13:51 <charliesome> i was seeing segfaults in ruby when the segv handler was called the second time

13:51 <charliesome> so if you have a C stack overflow, the segv handler is called and throws a SystemStackError

13:51 <charliesome> but the operating system still thinks ruby is using the alt stack

13:51 <_ko1> wait a miniut

13:51 <_ko1> r40402 changes all setjmp to sigsetjmp?

13:52 <charliesome> yes

13:52 <_ko1> i want to reject it because of performance perspective

13:52 <_ko1> your problem is too trivial, i think.

13:53 <charliesome> i did try a benchmark with many calls and i didn't notice any performance issues

13:53 <_ko1> ah, really?

13:53 <charliesome> let me double check now that you mention performance is an issue

13:54 <_ko1> sigsetjmp needs system calls

13:54 <_ko1> setjmp only need memory operations

13:54 <charliesome> _ko1: is that on linux?

13:54 <_ko1> linux

13:55 <charliesome> ah ok

13:55 <_ko1> please check strace

13:57 shiba___ has joined #ruby-core

13:57 <charliesome> _ko1: if i use dtruss (mac os x equivalent) i see no additional system calls

13:57 <charliesome> but on linux it's a problem

13:57 <_ko1> :(

13:59 <charliesome> actually

13:59 <_ko1> i'm not sure about newest linux, but i when measured, sigsetjmp is slower.

13:59 <_ko1> s/i when/when i/

14:00 <charliesome> _ko1: it's not noticeably slower for me

14:00 <_ko1> how about to make another solution for it?

14:00 <charliesome> i'm on a very new linux: 3.8.6

14:00 <charliesome> _ko1: that's what i wanted to ask about

14:01 <charliesome> _ko1: is there a reason ruby doesn't use libsigsegv? I believe it's used in a few other language implementations

14:03 <_ko1> what is livsigsegv?

14:03 <_ko1> i'm not sure

14:04 <charliesome> _ko1: http://www.gnu.org/software/libsigsegv/ cross platform segv/stack overflow handling

14:05 <_ko1> 23:04:51 ko1@sasada-8core:~/ruby/build$ time ./miniruby -ve '5_000_000.times{1.times{}}'

14:05 <_ko1> ruby 2.1.0dev (2013-04-21 trunk 40402) [x86_64-linux]

14:05 <_ko1> real 0m3.393s

14:05 <_ko1> user 0m1.904s

14:05 <_ko1> sys 0m1.488s

14:05 <_ko1> 23:04:58 ko1@sasada-8core:~/ruby/build$ time ../versions/install-trunk-daily_2013-04-16T12_00/bin/ruby -ve '5_000_000.times{1.times{}}'

14:05 <_ko1> ruby 2.1.0dev (2013-04-16 trunk 40318) [x86_64-linux]

14:05 <_ko1> real 0m1.221s

14:05 <_ko1> user 0m1.216s

14:05 <_ko1> sys 0m0.008s

14:05 <_ko1> significant impact for me

14:05 <_ko1> Linux 2.6.32-5-amd64

14:05 <charliesome> _ko1: i'll revert it then

14:06 <_ko1> maybe it seems Linux 3.?? solve this one :)

14:06 <charliesome> _ko1: i think so, however there are still many people using 2.6, so it's not acceptable

14:07 <_ko1> ok, so discussion is move to how to solve it.

14:07 <_ko1> (thank you for your acceptance)

14:07 <_ko1> libsigsegv solves this issue?

14:07 <charliesome> _ko1: or perhaps use sigsetjmp on platforms where it is not slower?

14:08 <_ko1> i believe ruby should not depend on sigsetjmp.

14:08 <_ko1> because ruby should not depend on signal status.

14:08 <_ko1> (for normal execution flow)

14:09 <_ko1> yet, i don't understand why sigsetjmp solve it

14:10 <_ko1> jump from where to where?

14:10 <charliesome> _ko1: the problem is that when ruby longjmps out of sigsegv, which is called on the alt stack

14:10 <_ko1> i believe there are no jump from segv handler to ruby codes.

14:10 <charliesome> _ko1: the operating system still thinks the signal handler is running

14:11 <charliesome> _ko1: https://github.com/ruby/ruby/blob/trunk/signal.c#L670

14:11 <_ko1> ah my god

14:11 <_ko1> i understand

14:11 <_ko1> i understand the problem

14:11 <_ko1> ohh

14:12 <_ko1> mmm

14:13 <_ko1> are there any way to restore signal status before longjmp?

14:13 <_ko1> (maybe nothing)

14:13 <charliesome> _ko1: it's very platform specific

14:13 <_ko1> yes.

14:14 <_ko1> it should be separate APIs.

14:14 <charliesome> _ko1: i think libsigsegv solves this well, but it needs further investigation

14:15 <_ko1> save_signal_status(&status); setjmp(jump) and siglongjmp(&status, jump)

14:15 <_ko1> ah, cool

14:15 <charliesome> _ko1: are you siglongjmp-ing to some code which performs a regular longjmp?

14:16 <charliesome> that could work

14:16 <_ko1> sorry i'm not sure what you want to say.

14:18 <charliesome> sigsetjmp and siglongjmp are only necessary to clear the SS_ONSTACK flag of the alt stack, so we could siglongjmp to a special piece of code that just raises a system stack error

14:18 <_ko1> i agree

14:19 <_ko1> [main] sigsetjmp(root) .... [foo] setjmp(bar) ...

14:20 <_ko1> [main] sigsetjmp(root) .... [foo] setjmp(bar) ... [segv handler] siglongjmp(root)

14:20 <_ko1> [main] longjmp(bar)

14:20 <charliesome> _ko1: yes

14:20 <_ko1> [main] sigsetjmp(root) .... [foo] setjmp(bar) ...

14:20 <_ko1> interesting!

14:21 <_ko1> but i'm not sure it can do (because jump to deeper place (longjmp(bar))

14:21 <charliesome> sigsetjmp would need to be on a separate stack

14:21 <_ko1> yes.

14:22 <charliesome> _ko1: do you think this is too complex?

14:22 <_ko1> not too complex, but i'm not sure it works fine

14:22 <_ko1> at least, i agree that current SEGV -> stack overflow flow has a bug if we use setjmp/longjmp.

14:24 <znz_jp> biff: [ruby-changes:28351] charliesome:r40403 (trunk): * configure.in: Revert using sigsetjmp by default due to performance - http://mla.n-z.jp/?ruby-changes=28351

14:25 <_ko1> on your Linux (3.8?), no system calls used by sigsetjmp?

14:26 <charliesome> _ko1: no

14:26 <_ko1> ah...

14:27 <_ko1> and i'm not sure we can use libsigsegv because of license

14:28 <charliesome> _ko1: ah that is annoyiong

14:29 <_ko1> i send a summary of this discussion.

14:29 <_ko1> thank you.

14:29 <charliesome> thank you too

14:29 shiba___ has quit [Ping timeout: 264 seconds]

14:30 <charliesome> goodnight

14:30 <_ko1> good night.

14:30 charliesome has quit [Quit: Textual IRC Client: www.textualapp.com]

14:30 nagachika has quit [Remote host closed the connection]

14:36 nagachika has joined #ruby-core

15:18 shiba___ has joined #ruby-core

16:37 nagachika has quit [Remote host closed the connection]

17:26 shiba___ has quit [Read error: Operation timed out]

19:31 Caius has joined #ruby-core

19:57 Caius has quit [Quit: ""]

19:58 Caius has joined #ruby-core

21:18 shirokuro11 has joined #ruby-core

21:18 shirokuro11 has quit [Remote host closed the connection]

21:19 shirokuro11 has joined #ruby-core

22:22 knu has quit [Ping timeout: 264 seconds]

22:24 nokada has joined #ruby-core

22:24 nokada_ has quit [Read error: Connection reset by peer]

23:01 idkazuma has joined #ruby-core

23:05 idkazuma has quit [Ping timeout: 260 seconds]

23:06 idkazuma has joined #ruby-core

23:16 idkazuma has quit [Remote host closed the connection]

23:17 agarie has joined #ruby-core

23:42 xibbar has joined #ruby-core

23:49 charliesome has joined #ruby-core

23:50 tenderlove has joined #ruby-core

23:55 rafaelfranca has quit [Read error: Connection reset by peer]

23:56 rafaelfranca has joined #ruby-core

23:58 idkazuma has joined #ruby-core