stored in variable while the contents buffer is beeing used.
* ext/date/date_parse.c (date_zone_to_diff): get rid of out of bounds
memory read.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@33106 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
the encoding of the format. On Windows (at least Japanese Windows),
Time#strftime("%Z") includes non ASCII in locale encoding (CP932).
So convert locale to default internal. [ruby-core:39092] [Bug #5226]
* strftime.c (rb_strftime): ditto.
* strftime.c (rb_strftime_timespec): ditto.
* internal.h (rb_strftime_timespec): follow above.
* time.c (rb_strftime_alloc): ditto.
* time.c (strftimev): ditto.
* time.c (time_strftime): ditto.
* time.c (time_to_s): the resulted string of Time#to_s is always
ascii only, so this should be US-ASCII.
* time.c (time_asctime): ditto.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@33094 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
What's the problem?
autoload is thread unsafe. When we define a constant to be
autoloaded, we expect the constant construction is invariant. But
current autoload implementation allows other threads to access the
constant while the first thread is loading a file.
What's happening inside?
The current implementation uses Qundef as a marker of autoload in
Constant table. Once the first thread find Qundef as a value at
constant lookup, it starts loading a defined feature. Generally a
loaded file overrides the Qundef in Constant table by module/class
declaration at very beginning lines of the file, so other threads
can see the new Module/Class object before feature loading is
finished. It breaks invariant construction.
How to solve?
To ensure invariant constant construction, we need to override
Qundef with defined Object after the feature loading. For keeping
Qundef in Constant table, I expanded autoload_data struct in
Module to have a slot for keeping the defined object while feature
loading. And changed Module's constant lookup/update logic a
little so that the slot is only visible from the thread which
invokes feature loading. (== the first thread which accessed the
autoload constant)
Evaluation?
All test passes (bootstrap test, test-all and RubySpec) and added
8 tests for threading behavior. Extra logics are executed only
when Qundef is found, so no perf drop should happen except
autoloading.
* variable.c (rb_autoload): Prepare new autoload_data struct.
* variable.c (rb_autoload_load): Load feature and update Constant
table after feature loading is finished.
* variable.c (rb_const_get_0): When the fetched constant is under
autoloading, it returns the object only for the thread which starts
autoloading.
* variable.c (rb_const_defined_0): Ditto.
* variable.c (rb_const_set): When the specified constant is under
autoloading, it sets the object only for the thread which starts
autoloading. Otherwise, simply overrides Qundef with constant
override warning.
* vm_insnhelper.c (vm_get_ev_const): Apply same change as
rb_const_get_0 in variable.c.
* test/ruby/test_autoload.rb: Added tests for threading behavior.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@33078 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
creating ruby-format gemspecs. Fixes Gem.dir not being at the front
of Gem.path to fix uninstall and cleanup commands. Fixes gem
uninstall stopping on the first missing gem.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@33074 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
fixes: Bug #2729
a patch from Kazuki Tsujimoto <kazuki@callcc.net>
This problem is caused by changing dfp (dynamic env pointer)
from saved dfp. Saved dfp is pointed env in VM stack. However,
the dfp can be moved because VM copies env from VM stack to
the heap. At this copying, dfp was also changed. To solve this
problem, I'll try to change throw mechanism (not save target dfp,
but save target cfp).
* bootstraptest/test_flow.rb: add a test for above.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@33064 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Manage a redefinition of special methods for each classes.
A patch from Joel Gouly <joel.gouly@gmail.com>. Thanks!
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@33059 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
should be manipulated because master pty may not be a tty on some
environment (e.g. Solaris). [Bug:#5222] [ruby-dev:44420]
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@33049 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
to solve an issue reported at [ruby-dev:44413] [Ruby 1.9 - Bug #5217].
Before this fix, each instruction has an information including
line number (iseq::iseq_insn_info_table). Instead of this data
structure, recording only line number changing places
(iseq::iseq_line_info_table).
The order of entries in iseq_line_info_table is ascending order of
iseq_line_info_table_entry::position. You can get a line number
by an iseq and a program counter with this data structure.
This fix reduces memory consumption of iseq (bytecode).
On my measurement, a rails application consumes 21.8MB for
iseq with this fix on the 32bit CPU. Without this fix, it
consumes 24.7MB for iseq [ruby-dev:44415].
* proc.c: ditto.
* vm_insnhelper.c: ditto.
* vm_method.c: ditto.
* vm.c (rb_vm_get_sourceline): change to use rb_iseq_line_no().
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@33046 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
A patch by Magnus Holm <judofyr@gmail.com>. Thanks!
* test/ruby/test_variable.rb: add a test for above.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@33045 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
HTTPS image paths to be turned into <img> tags. Prevents special
markup inside <tt> from being processed.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@33043 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
line is out of the way. rb_sourceline() is unreliable when source
code is big. [ruby-dev:44413]
* test/coverage/test_coverage.rb: add a test for above.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@33030 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
gzip header is readable to avoid SEGV.
* test/zlib/test_zlib.rb (test_corrupted_header): Test it.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@33023 b2dd03c8-39d4-4d8f-98ff-823fe69b080e