Skip Menu |

This queue is for tickets about the JSON-XS CPAN distribution.

Report information
The Basics
Id: 88061
Status: resolved
Priority: 0/
Queue: JSON-XS

People
Owner: Nobody in particular
Requestors: ulisse.monari [...] tper.it
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Subject: problem (bug?) in json_decode for floating point numbers under AIX
Date: Fri, 23 Aug 2013 16:09:23 +0200
To: bug-JSON-XS [...] rt.cpan.org
From: Ulisse Monari <ulisse.monari [...] tper.it>
hi. distribution: JSON-XS-2.33 perl -v : "This is perl, v5.8.8 built for aix-thread-multi" uname -a: AIX srv-dev1 3 5 000B2CC2D700 (AIX 5.3) gcc -v: gcc version 2.9-aix51-020209 After obtaining "Segmentation fault(coredump)" i found the cause into the Perl_pow(...) call within json_atof_scan1 . The aix error log report this: Detail Data SIGNAL NUMBER 11 USER'S PROCESS ID: 545012 FILE SYSTEM SERIAL NUMBER 11 INODE NUMBER 74303 CORE FILE NAME /app/instdir/p588/JSON-XS-2.33/core PROGRAM NAME perl STACK EXECUTION DISABLED 0 COME FROM ADDRESS REGISTER PROCESSOR ID hw_fru_id: 0 hw_cpu_id: 0 ADDITIONAL INFORMATION move 34 move 30 pow 10C json_atof 1D8 json_atof 90 json_atof 54 decode_nu 6EC decode_sv 1F8 decode_av 8C decode_sv 1D4 decode_hv 1DC decode_sv 1EC decode_js 21C XS_JSON__ 16C Perl_pp_e 5E8 Perl_runo 54 S_run_bod 170 perl_run 90 main E8 __start 9C My workaround (not so very good) in the attachment. The same json text parse OK under perl/XS in linux and via php/json_decode and java/mjson Here more details about my env: perl -V Summary of my perl5 (revision 5 version 8 subversion 8) configuration: Platform: osname=aix, osvers=5.3.0.0, archname=aix-thread-multi uname='aix srv_dev1 3 5 000b2cc2d700 powerpc unknown aix ' config_args='-Dcc=gcc -Duselargefiles -Dusethreads -Dprefix=/usr/local -de' hint=recommended, useposix=true, d_sigaction=define usethreads=define use5005threads=undef useithreads=define usemultiplicity=define useperlio=define d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='gcc', ccflags ='-D_THREAD_SAFE -D_ALL_SOURCE -D_ANSI_C_SOURCE -D_POSIX_SOURCE -DUSE_NATIVE_DLOPEN -DNEED_PTHREAD_INIT -fno-strict-aliasing -pipe -D_LARGE_FILES', optimize='-O', cppflags='-D_THREAD_SAFE -D_ALL_SOURCE -D_ANSI_C_SOURCE -D_POSIX_SOURCE -DUSE_NATIVE_DLOPEN -DNEED_PTHREAD_INIT -fno-strict-aliasing -pipe' ccversion='', gccversion='2.9-aix51-020209', gccosandvers='aix5.1.0.0' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=4321 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=8 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=8, prototype=define Linker and Libraries: ld='gcc', ldflags =' -Wl,-brtl -Wl,-bdynamic -Wl,-bmaxdata:0x80000000 -Wl,-b32' libpth=/lib /usr/lib /usr/ccs/lib libs=-lbind -lnsl -ldbm -ldl -lld -lm -lcrypt -lpthreads -lc -lbsd perllibs=-lbind -lnsl -ldl -lld -lm -lcrypt -lpthreads -lc -lbsd libc=/lib/libc.a, so=a, useshrplib=false, libperl=libperl.a gnulibc_version='' Dynamic Linking: dlsrc=dl_aix.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Xlinker -bE:/usr/local/lib/perl5/5.8.8/aix-thread-multi/CORE/perl.exp' cccdlflags=' ', lddlflags=' -Wl,-bhalt:4 -Wl,-bexpall -Wl,-G -Wl,-bnoentry -lpthreads -lc' Characteristics of this binary (from libperl): Compile-time options: MULTIPLICITY PERL_IMPLICIT_CONTEXT PERL_MALLOC_WRAP USE_ITHREADS USE_LARGE_FILES USE_PERLIO USE_REENTRANT_API Built under aix Compiled at Aug 12 2008 08:35:26 @INC: /usr/local/lib/perl5/5.8.8/aix-thread-multi /usr/local/lib/perl5/5.8.8 /usr/local/lib/perl5/site_perl/5.8.8/aix-thread-multi /usr/local/lib/perl5/site_perl/5.8.8 /usr/local/lib/perl5/site_perl . ------------------------------------ gccdefs... cat << TAG > tmp.c main() { printf("short size %d\n",sizeof(short)); printf("int size %d \n",sizeof(int)); printf("long size %d\n",sizeof(long)); printf("float size %d \n",sizeof(float)); printf("double size %d\n",sizeof(double)); printf("long long size %d \n",sizeof(long long)); } TAG gcc -E -v tmp.c gcc tmp.c && ./a.out rm tmp.c a.out 2>/dev/null ------------------- Reading specs from /usr/bin/../lib/gcc-lib/powerpc-ibm-aix5.1.0.0/2.9-aix51-020209/specs gcc version 2.9-aix51-020209 /usr/bin/../lib/gcc-lib/powerpc-ibm-aix5.1.0.0/2.9-aix51-020209/cpp -lang-c -v -iprefix /usr/bin/../lib/gcc-lib/powerpc-ibm-aix5.1.0.0/2.9-aix51-020209/ -D__GNUC__=2 -D__GNUC_MINOR__=9 -D_IBMR2 -D_POWER -D_AIX -D_AIX32 -D_AIX41 -D_AIX43 -D_AIX51 -D_LONG_LONG -D_IBMR2 -D_POWER -D_AIX -D_AIX32 -D_AIX41 -D_AIX43 -D_AIX51 -D_LONG_LONG -Asystem(unix) -Asystem(aix) -D__CHAR_UNSIGNED__ -D_ARCH_COM tmp.c GNU CPP version 2.9-aix51-020209 #include "..." search starts here: #include <...> search starts here: /usr/bin/../lib/gcc-lib/powerpc-ibm-aix5.1.0.0/2.9-aix51-020209/../../../../powerpc-ibm-aix5.1.0.0/include /usr/bin/../lib/gcc-lib/powerpc-ibm-aix5.1.0.0/2.9-aix51-020209/include /opt/freeware/GNUPro/include /opt/freeware/GNUPro/lib/gcc-lib/powerpc-ibm-aix5.1.0.0/2.9-aix51-020209/../../../../powerpc-ibm-aix5.1.0.0/include /opt/freeware/GNUPro/lib/gcc-lib/powerpc-ibm-aix5.1.0.0/2.9-aix51-020209/include /usr/include End of search list. The following default directories have been omitted from the search path: /opt/freeware/GNUPro/lib/gcc-lib/powerpc-ibm-aix5.1.0.0/2.9-aix51-020209/../../../../include/g++-3 End of omitted list. # 1 "tmp.c" main() { printf("short size %d\n",sizeof(short)); printf("int size %d \n",sizeof(int)); printf("long size %d\n",sizeof(long)); printf("float size %d \n",sizeof(float)); printf("double size %d\n",sizeof(double)); printf("long long size %d \n",sizeof(long long)); } short size 2 int size 4 long size 4 float size 4 double size 8 long long size 8 Bye Ulisse -- ======================================================= ulisse.monari@tper.it TPER SpA - Trasporto Passeggeri Emilia-Romagna (IT) Sistemi Informativi & Sviluppo Tecnologico tel. +039.051.350527 fax. +039.051.350506 ======================================================= This msg is an info/comm which doesn't legally bind TPER =======================================================

Message body is not shown because sender requested not to inline it.

Message body is not shown because sender requested not to inline it.

Subject: Re: [rt.cpan.org #88061] problem (bug?) in json_decode for floating point numbers under AIX
Date: Fri, 23 Aug 2013 17:51:51 +0200
To: Ulisse Monari via RT <bug-JSON-XS [...] rt.cpan.org>
From: Marc Lehmann <schmorp [...] schmorp.de>
Hi! Please send your bug report it to the official contact/author address for the module in question (or send it to rt.cpan.org@schmorp.de, that's fine as well). What follows is the rationale for this request, you don't have to read it if you don't care. Why is this necessary? rt.cpan.org has many deficiencies which makes it tedious and hard to use, increasing the workload on the people who provide all the perl modules you probably appreciate (and that is really to be avoided - module authors should be able to invest all their time into improving their modules and not fighting with rt.cpan.org's bugs). Still, for some people, rt.cpan.org is useful to have, and some people even like it and really want to use it. That is fine, too. Unfortunately, the designers of rt.cpan.org didn't make their "service" optional - you can neither opt-in nor opt-out of rt.cpan.org as a module author. Just like a spammer, rt.cpan.org forces its "service" (whether wanted or unwanted) on everybody. Just like a spammer, they don't care for the people they actively hurt. Just like a spammer, they don't don't care to fix these issues and make their "service" ethically acceptable. You cannot even configure it to redirect tickets to somewhere else. Unfortunately, ignoring rt.cpan.org is not an option either: for people reporting possible bugs there is no indication that their report will be ignored, and for module authors it means they miss potentially vital bug reports such as yours (and of course it's a great impression if rt.cpan.org has lots of bug reports that are unanswered, making a module look unmaintained when in fact the opposite might be true). I am sorry that this wasted a bit of your time, but please understand that I am just as much a victim as you are - the problem is the unethical stance of the rt.cpan.org providers who force their "service" on everybody. Please redirect your bug report as stated in the beginning of this mail, and please consider petitioning the rt.cpan.org providers to stop their unethical behaviour and allow opt-in, opt-out, or some redirect option. One last issue: many people mail me that this can be "fixed" by including the bugtracker element in my module meta file. This is not true: 1. This field only affects search.cpan.org and maybe similar services. (Many people confuse rt.cpan.org with search.cpan.org for some reason). 2. It doesn't even work (there are still links to rt.cpan.org displayed). 3. Even if search.cpan.org does no longer display the link, it doesn't actually affect rt.cpan.org (and tests have shown that people go to rt.cpan.org regardless) Even *iff* rt.cpan.org would start listening on the bugtracker field, however, it's still wrong. I have a lot of modules, and each time a service like rt.cpan.org comes out, I would have to make dummy releases for all my modules. This not only creates a lot of extra work for me (I take releases very seriously) but also users, who would wonder why there is a new release. Thanks a lot, Marc Lehmann <rt.cpan.org@schmorp.de> Last updated: 2012-04-22
See also the fix in https://github.com/rurban/Cpanel-JSON-XS/issues/11 Cpanel-JSON-XS-2.3403
Subject: Re: [rt.cpan.org #88061] problem (bug?) in json_decode for floating point numbers under AIX
Date: Sun, 3 Nov 2013 14:20:22 +0100
To: Reini Urban via RT <bug-JSON-XS [...] rt.cpan.org>
From: Marc Lehmann <schmorp [...] schmorp.de>
Hi! Please send your bug report it to the official contact/author address for the module in question (or send it to rt.cpan.org@schmorp.de, that's fine as well). What follows is the rationale for this request, you don't have to read it if you don't care. Why is this necessary? rt.cpan.org has many deficiencies which makes it tedious and hard to use, increasing the workload on the people who provide all the perl modules you probably appreciate (and that is really to be avoided - module authors should be able to invest all their time into improving their modules and not fighting with rt.cpan.org's bugs). Still, for some people, rt.cpan.org is useful to have, and some people even like it and really want to use it. That is fine, too. Unfortunately, the designers of rt.cpan.org didn't make their "service" optional - you can neither opt-in nor opt-out of rt.cpan.org as a module author. Just like a spammer, rt.cpan.org forces its "service" (whether wanted or unwanted) on everybody. Just like a spammer, they don't care for the people they actively hurt. Just like a spammer, they don't don't care to fix these issues and make their "service" ethically acceptable. You cannot even configure it to redirect tickets to somewhere else. Unfortunately, ignoring rt.cpan.org is not an option either: for people reporting possible bugs there is no indication that their report will be ignored, and for module authors it means they miss potentially vital bug reports such as yours (and of course it's a great impression if rt.cpan.org has lots of bug reports that are unanswered, making a module look unmaintained when in fact the opposite might be true). I am sorry that this wasted a bit of your time, but please understand that I am just as much a victim as you are - the problem is the unethical stance of the rt.cpan.org providers who force their "service" on everybody. Please redirect your bug report as stated in the beginning of this mail, and please consider petitioning the rt.cpan.org providers to stop their unethical behaviour and allow opt-in, opt-out, or some redirect option. One last issue: many people mail me that this can be "fixed" by including the bugtracker element in my module meta file. This is not true: 1. This field only affects search.cpan.org and maybe similar services. (Many people confuse rt.cpan.org with search.cpan.org for some reason). 2. It doesn't even work (there are still links to rt.cpan.org displayed). 3. Even if search.cpan.org does no longer display the link, it doesn't actually affect rt.cpan.org (and tests have shown that people go to rt.cpan.org regardless) Even *iff* rt.cpan.org would start listening on the bugtracker field, however, it's still wrong. I have a lot of modules, and each time a service like rt.cpan.org comes out, I would have to make dummy releases for all my modules. This not only creates a lot of extra work for me (I take releases very seriously) but also users, who would wonder why there is a new release. Thanks a lot, Marc Lehmann <rt.cpan.org@schmorp.de> Last updated: 2012-04-22