Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Default encoding for Ruby 1.9 #7

Closed
nono opened this issue Mar 26, 2012 · 1 comment
Closed

Default encoding for Ruby 1.9 #7

nono opened this issue Mar 26, 2012 · 1 comment

Comments

@nono
Copy link

nono commented Mar 26, 2012

Hi,

I think Oj should respect the default encoding on Ruby 1.9. For example, I'd expect an UTF-8 string when dumping a hash in this context:

[1] pry(main)> puts Encoding.default_external
UTF-8
=> nil
[2] pry(main)> require "oj"
=> true
[3] pry(main)> puts Oj.dump(foo: "éà").encoding
ASCII-8BIT
@ohler55
Copy link
Owner

ohler55 commented Mar 26, 2012

UTF-8 is the default in 1.1.0 instead of the Ruby default encoding.

@ohler55 ohler55 closed this as completed Mar 26, 2012
ohler55 added a commit that referenced this issue Jul 23, 2017
@ohler55
# This is a combination of 8 commits.
6b791b9 
# This is the 1st commit message:
Empty appveyor

Added more to appveyer

# This is the commit message #2:

turn build on

# This is the commit message #3:

added build script

# This is the commit message #4:

added build script

# This is the commit message #5:

commented out make clean

# This is the commit message #6:

trying gem install

# This is the commit message #7:

trying a path

# This is the commit message #8:

corrected path for windows
tonobo added a commit to tonobo/oj that referenced this issue Jun 1, 2022
@tonobo
dump: Fix double free in oj_write_obj_to_file
6b33d45 
We encountered a segfault by dumping json in certain conditions. There seems to be an obsolete fclose which is likely caused by an merge / rebase fault.

Backtrace:

```gdb
 #0  0x00007f00b459a00b in raise () from /lib/x86_64-linux-gnu/libc.so.6
 ohler55#1  0x00007f00b4579859 in abort () from /lib/x86_64-linux-gnu/libc.so.6
 ohler55#2  0x00007f00b45e426e in ?? () from /lib/x86_64-linux-gnu/libc.so.6
 ohler55#3  0x00007f00b45ec2fc in ?? () from /lib/x86_64-linux-gnu/libc.so.6
 ohler55#4  0x00007f00b45edf6d in ?? () from /lib/x86_64-linux-gnu/libc.so.6
 ohler55#5  0x00007f00b45d8ec3 in fclose () from /lib/x86_64-linux-gnu/libc.so.6
 ohler55#6  0x00007f00b001541e in oj_write_obj_to_file (obj=93852459311840, path=<optimized out>, copts=copts@entry=0x7ffd9c5debb0) at dump.c:624
 ohler55#7  0x00007f00b002c9f6 in to_file (argc=<optimized out>, argv=0x7f00b3ed4ed0, self=<optimized out>) at oj.c:1364
 ohler55#8  0x00007f00b4957026 in vm_call_cfunc_with_frame (empty_kw_splat=<optimized out>, cd=0x555bbaa578d0, calling=<optimized out>, reg_cfp=0x7f00b3fd2e90,
     ec=0x555bb87dc600) at vm_insnhelper.c:2514
 ohler55#9  vm_call_cfunc (ec=0x555bb87dc600, reg_cfp=0x7f00b3fd2e90, calling=<optimized out>, cd=0x555bbaa578d0) at vm_insnhelper.c:2539
 ohler55#10 0x00007f00b4963dab in vm_call_method (ec=0x555bb87dc600, cfp=0x7f00b3fd2e90, calling=<optimized out>, cd=<optimized out>) at vm_insnhelper.c:3053
 ohler55#11 0x00007f00b494a406 in vm_sendish (ec=ec@entry=0x555bb87dc600, reg_cfp=reg_cfp@entry=0x7f00b3fd2e90, cd=0x555bbaa578d0,
     block_handler=block_handler@entry=0, method_explorer=method_explorer@entry=0x7f00b4950d80 <vm_search_method_wrap>) at vm_insnhelper.c:4023
 ohler55#12 0x00007f00b495b0ba in vm_exec_core (ec=<optimized out>, initial=<optimized out>) at insns.def:801
 ohler55#13 0x00007f00b4961870 in rb_vm_exec (ec=0x555bb87dc600, mjit_enable_p=1) at vm.c:2090
 ohler55#14 0x00007f00b4965918 in vm_call0_body (ec=0x555bb87dc600, calling=0x7ffd9c5df1a0, cd=<optimized out>, argv=0x7ffd9c5df370) at vm_eval.c:136
...
```
ohler55 pushed a commit that referenced this issue Jun 1, 2022
@tonobo
dump: Fix double free in oj_write_obj_to_file (#768)
74b4bbf 
We encountered a segfault by dumping json in certain conditions. There seems to be an obsolete fclose which is likely caused by an merge / rebase fault.

Backtrace:

```gdb
 #0  0x00007f00b459a00b in raise () from /lib/x86_64-linux-gnu/libc.so.6
 #1  0x00007f00b4579859 in abort () from /lib/x86_64-linux-gnu/libc.so.6
 #2  0x00007f00b45e426e in ?? () from /lib/x86_64-linux-gnu/libc.so.6
 #3  0x00007f00b45ec2fc in ?? () from /lib/x86_64-linux-gnu/libc.so.6
 #4  0x00007f00b45edf6d in ?? () from /lib/x86_64-linux-gnu/libc.so.6
 #5  0x00007f00b45d8ec3 in fclose () from /lib/x86_64-linux-gnu/libc.so.6
 #6  0x00007f00b001541e in oj_write_obj_to_file (obj=93852459311840, path=<optimized out>, copts=copts@entry=0x7ffd9c5debb0) at dump.c:624
 #7  0x00007f00b002c9f6 in to_file (argc=<optimized out>, argv=0x7f00b3ed4ed0, self=<optimized out>) at oj.c:1364
 #8  0x00007f00b4957026 in vm_call_cfunc_with_frame (empty_kw_splat=<optimized out>, cd=0x555bbaa578d0, calling=<optimized out>, reg_cfp=0x7f00b3fd2e90,
     ec=0x555bb87dc600) at vm_insnhelper.c:2514
 #9  vm_call_cfunc (ec=0x555bb87dc600, reg_cfp=0x7f00b3fd2e90, calling=<optimized out>, cd=0x555bbaa578d0) at vm_insnhelper.c:2539
 #10 0x00007f00b4963dab in vm_call_method (ec=0x555bb87dc600, cfp=0x7f00b3fd2e90, calling=<optimized out>, cd=<optimized out>) at vm_insnhelper.c:3053
 #11 0x00007f00b494a406 in vm_sendish (ec=ec@entry=0x555bb87dc600, reg_cfp=reg_cfp@entry=0x7f00b3fd2e90, cd=0x555bbaa578d0,
     block_handler=block_handler@entry=0, method_explorer=method_explorer@entry=0x7f00b4950d80 <vm_search_method_wrap>) at vm_insnhelper.c:4023
 #12 0x00007f00b495b0ba in vm_exec_core (ec=<optimized out>, initial=<optimized out>) at insns.def:801
 #13 0x00007f00b4961870 in rb_vm_exec (ec=0x555bb87dc600, mjit_enable_p=1) at vm.c:2090
 #14 0x00007f00b4965918 in vm_call0_body (ec=0x555bb87dc600, calling=0x7ffd9c5df1a0, cd=<optimized out>, argv=0x7ffd9c5df370) at vm_eval.c:136
...
```
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@nono @ohler55