This is not a bug in memr or j engine. those memory are protected, I bet it will also crash if a C program read those memory location. The bug should be the if conditional block in sax callback. please also check how the api/expat handle the callback.
09.03.2014, в 4:37, Raul Miller <[email protected]> написал(а): > The crash happens in memchr/ > > And that explains the stack trace. (Roger probably knew that already and is > just trying to coach us in understanding the code.) > > > memchr_psax_ > ┌────┬─┬─────────────────┐ > │memr│@│┌─┬─────────────┐│ > │ │ ││,│┌─┬─┬───────┐││ > │ │ ││ ││0│,│┌─┬─┬─┐│││ > │ │ ││ ││ │ ││,│&│2││││ > │ │ ││ ││ │ │└─┴─┴─┘│││ > │ │ ││ │└─┴─┴───────┘││ > │ │ │└─┴─────────────┘│ > └────┴─┴─────────────────┘ > 9!:3]5 > > memchr_psax_ > memr@(, (0 , ,&2)) > memr_psax_ > 15!:1 > > So I expect that this is a word alignment issue in the implementation of > 15!:1 > > Here's an example of data being passed to memr: > _18080 0 1 2 > > According to http://www.jsoftware.com/user/memory_management.htm: > address: _18080 > offset: 0 > count: 1 > type: 2 (literal) > > It's no clear to me why __memmove_ssse3_back() should be called when > getting a single character. This might be a bug in ubuntu's implementation > of memcpy? > > Thanks, > > -- > Raul > > > > On Fri, Mar 7, 2014 at 10:09 PM, bill lam <[email protected]> wrote: > >> If you look at the callback inside sax.ijs >> >> cdcallback=: 3 : 0 >> if. 3=#y do. >> if. PARLEN(> *. 0<])2{y do. >> characters^:(*@#) trim^:IGNOREWS memchr/}.y return.end. >> (2{y) startElement memstr 1{y >> else. >> endElement memstr 1{y >> end. >> ) >> >> it tries to distinguish between 2 callbacks with the same >> number of parameters by using the condition, >> if. PARLEN(> *. 0<])2{y do. >> >> if you want to debug, this probably is the place to begin with. >> >> Пт, 07 мар 2014, Raul Miller писал(а): >>> I get what looks like the same crash from j64-602's jconsole: >>> >>> 9!:14'' >>> j602/2008-03-03/16:45 >>> >>> #0 __memmove_ssse3_back () at >>> ../sysdeps/x86_64/multiarch/memcpy-ssse3-back.S:2253 >>> #1 0x00007ffff715d9fb in jtvec () from /home/ubuntu/j64-602/bin/libj.so >>> #2 0x00007ffff7286faa in jtmemr () from /home/ubuntu/j64-602/bin/libj.so >>> #3 0x00007ffff728268f in secf1 () from /home/ubuntu/j64-602/bin/libj.so >>> #4 0x00007ffff71084fd in jtdfs1 () from /home/ubuntu/j64-602/bin/libj.so >>> #5 0x00007ffff7156d41 in jtunquote () from >> /home/ubuntu/j64-602/bin/libj.so >>> #6 0x00007ffff710a0c3 in jtupon2 () from >> /home/ubuntu/j64-602/bin/libj.so >>> #7 0x00007ffff7108546 in jtdfs2 () from /home/ubuntu/j64-602/bin/libj.so >>> #8 0x00007ffff7156cb9 in jtunquote () from >> /home/ubuntu/j64-602/bin/libj.so >>> #9 0x00007ffff70fc4c6 in jtredg () from /home/ubuntu/j64-602/bin/libj.so >>> #10 0x00007ffff70fe34f in jtreduce () from >> /home/ubuntu/j64-602/bin/libj.so >>> #11 0x00007ffff71084fd in jtdfs1 () from /home/ubuntu/j64-602/bin/libj.so >>> #12 0x00007ffff7149d64 in jtmonad () from >> /home/ubuntu/j64-602/bin/libj.so >>> #13 0x00007ffff7149869 in jtparsea () from >> /home/ubuntu/j64-602/bin/libj.so >>> #14 0x00007ffff713728e in jtparsex () from >> /home/ubuntu/j64-602/bin/libj.so >>> #15 0x00007ffff7132bbc in jtxdefn () from >> /home/ubuntu/j64-602/bin/libj.so >>> #16 0x00007ffff71084fd in jtdfs1 () from /home/ubuntu/j64-602/bin/libj.so >>> #17 0x00007ffff7156d41 in jtunquote () from >> /home/ubuntu/j64-602/bin/libj.so >>> #18 0x00007ffff71084fd in jtdfs1 () from /home/ubuntu/j64-602/bin/libj.so >>> #19 0x00007ffff7149d64 in jtmonad () from >> /home/ubuntu/j64-602/bin/libj.so >>> #20 0x00007ffff7149869 in jtparsea () from >> /home/ubuntu/j64-602/bin/libj.so >>> #21 0x00007ffff7149a29 in jtparse () from >> /home/ubuntu/j64-602/bin/libj.so >>> #22 0x00007ffff714c9e7 in jtexec1 () from >> /home/ubuntu/j64-602/bin/libj.so >>> #23 0x00007ffff728698f in cb3 () from /home/ubuntu/j64-602/bin/libj.so >>> #24 0x00007ffff6a7cb11 in ?? () from /lib/x86_64-linux-gnu/libexpat.so.1 >>> #25 0x00007ffff6a7d64e in ?? () from /lib/x86_64-linux-gnu/libexpat.so.1 >>> #26 0x00007ffff6a7b9e1 in ?? () from /lib/x86_64-linux-gnu/libexpat.so.1 >>> #27 0x00007ffff6a7c16d in ?? () from /lib/x86_64-linux-gnu/libexpat.so.1 >>> #28 0x00007ffff6a7f5df in XML_ParseBuffer () from >>> /lib/x86_64-linux-gnu/libexpat.so.1 >>> #29 0x00007ffff72886f8 in docall () from /home/ubuntu/j64-602/bin/libj.so >>> #30 0x00007ffff728a4d8 in jtcdexec1 () from >> /home/ubuntu/j64-602/bin/libj.so >>> #31 0x00007ffff728ae34 in jtcd () from /home/ubuntu/j64-602/bin/libj.so >>> #32 0x00007ffff72826d0 in secf2 () from /home/ubuntu/j64-602/bin/libj.so >>> #33 0x00007ffff710ac83 in withl () from /home/ubuntu/j64-602/bin/libj.so >>> #34 0x00007ffff71084fd in jtdfs1 () from /home/ubuntu/j64-602/bin/libj.so >>> #35 0x00007ffff7156d41 in jtunquote () from >> /home/ubuntu/j64-602/bin/libj.so >>> #36 0x00007ffff71084fd in jtdfs1 () from /home/ubuntu/j64-602/bin/libj.so >>> #37 0x00007ffff7149d64 in jtmonad () from >> /home/ubuntu/j64-602/bin/libj.so >>> #38 0x00007ffff7149869 in jtparsea () from >> /home/ubuntu/j64-602/bin/libj.so >>> #39 0x00007ffff713728e in jtparsex () from >> /home/ubuntu/j64-602/bin/libj.so >>> #40 0x00007ffff7132796 in jtxdefn () from >> /home/ubuntu/j64-602/bin/libj.so >>> #41 0x00007ffff71084fd in jtdfs1 () from /home/ubuntu/j64-602/bin/libj.so >>> #42 0x00007ffff7156d41 in jtunquote () from >> /home/ubuntu/j64-602/bin/libj.so >>> #43 0x00007ffff71084fd in jtdfs1 () from /home/ubuntu/j64-602/bin/libj.so >>> #44 0x00007ffff7149d64 in jtmonad () from >> /home/ubuntu/j64-602/bin/libj.so >>> #45 0x00007ffff7149869 in jtparsea () from >> /home/ubuntu/j64-602/bin/libj.so >>> #46 0x00007ffff713728e in jtparsex () from >> /home/ubuntu/j64-602/bin/libj.so >>> #47 0x00007ffff7132bbc in jtxdefn () from >> /home/ubuntu/j64-602/bin/libj.so >>> #48 0x00007ffff71084fd in jtdfs1 () from /home/ubuntu/j64-602/bin/libj.so >>> #49 0x00007ffff7156d41 in jtunquote () from >> /home/ubuntu/j64-602/bin/libj.so >>> #50 0x00007ffff71084fd in jtdfs1 () from /home/ubuntu/j64-602/bin/libj.so >>> #51 0x00007ffff7149d64 in jtmonad () from >> /home/ubuntu/j64-602/bin/libj.so >>> #52 0x00007ffff7149869 in jtparsea () from >> /home/ubuntu/j64-602/bin/libj.so >>> #53 0x00007ffff713728e in jtparsex () from >> /home/ubuntu/j64-602/bin/libj.so >>> ... >>> >>> Am I going to have to give up using the xml/sax addon? >>> >>> Thanks, >>> >>> -- >>> Raul >>> >>> >>> >>> On Fri, Mar 7, 2014 at 7:48 PM, Raul Miller <[email protected]> >> wrote: >>> >>>> I did not compile the libj myself - it was a straight download of the >>>> standard install, followed by install'all'. >>>> >>>> The issue also occurs in J7 (same procedure) >>>> >>>> I am trying to figure out how to install the addons in J6 (this is on a >>>> remote linux box and I'm not running X on my local machine). I get >> value >>>> error for both install and jpkg in jconsole. >>>> >>>> Thanks, >>>> >>>> -- >>>> Raul >>>> >>>> >>>> >>>> >>>> On Fri, Mar 7, 2014 at 6:52 PM, bill lam <[email protected]> wrote: >>>> >>>>> Did you compile the libj yourself? If so, please also test with the >>>>> official libj. >>>>> >>>>> 08.03.2014, в 1:29, Raul Miller <[email protected]> написал(а): >>>>> >>>>>> If @ or f/ was involved, it was not code that I wrote. >>>>>> >>>>>> The callback code that I provided for sax was dead simple: explicit >>>>>> definitions with =: , ,. = # < }: '' 0 1 and one if. statement. >>>>>> >>>>>> I'll put a couple more J installs on my todo list for today, and >> expect >>>>> to >>>>>> be sticking with J6 for now. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> -- >>>>>> Raul >>>>>> >>>>>> >>>>>> >>>>>> On Fri, Mar 7, 2014 at 11:47 AM, Roger Hui < >> [email protected] >>>>>> wrote: >>>>>> >>>>>>> I understand GIGO but it was still doing f/ with that garbage, >> where f >>>>>>> contained @ or @: . >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Fri, Mar 7, 2014 at 8:34 AM, bill lam <[email protected]> >> wrote: >>>>>>> >>>>>>>> I suspect the crash is un-related to J engine but the sax addon >>>>>>>> script mixed up different callbacks. >>>>>>>> >>>>>>>> Пт, 07 мар 2014, Roger Hui писал(а): >>>>>>>>> The stuff near the top of the stack shows that it's doing >> something >>>>>>> with >>>>>>>> a >>>>>>>>> monad f/ where f has an @ or @: . >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Fri, Mar 7, 2014 at 7:42 AM, Raul Miller < >> [email protected]> >>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Hopefully this is the right forum for this. >>>>>>>>>> >>>>>>>>>> I'm running j8 stable on a linux box, with xml/sax and it >> segfaults >>>>>>> on >>>>>>>> me: >>>>>>>>>> >>>>>>>>>> #0 __memmove_ssse3_back () at >>>>>>>>>> ../sysdeps/x86_64/multiarch/memcpy-ssse3-back.S:2253 >>>>>>>>>> #1 0x00007ffff715989b in jtvec () from >>>>>>>> /home/ubuntu/j64-801/bin/libj.so >>>>>>>>>> #2 0x00007ffff728211a in jtmemr () from >>>>>>>> /home/ubuntu/j64-801/bin/libj.so >>>>>>>>>> #3 0x00007ffff7280abf in secf1 () from >>>>>>>> /home/ubuntu/j64-801/bin/libj.so >>>>>>>>>> #4 0x00007ffff7101ded in jtdfs1 () from >>>>>>>> /home/ubuntu/j64-801/bin/libj.so >>>>>>>>>> #5 0x00007ffff7152bca in jtunquote () from >>>>>>>>>> /home/ubuntu/j64-801/bin/libj.so >>>>>>>>>> #6 0x00007ffff71046e5 in jtupon2 () from >>>>>>>> /home/ubuntu/j64-801/bin/libj.so >>>>>>>>>> #7 0x00007ffff7101e36 in jtdfs2 () from >>>>>>>> /home/ubuntu/j64-801/bin/libj.so >>>>>>>>>> #8 0x00007ffff7152b47 in jtunquote () from >>>>>>>>>> /home/ubuntu/j64-801/bin/libj.so >>>>>>>>>> #9 0x00007ffff70f5d26 in jtredg () from >>>>>>>> /home/ubuntu/j64-801/bin/libj.so >>>>>>>>>> #10 0x00007ffff70f7baf in jtreduce () from >>>>>>>> /home/ubuntu/j64-801/bin/libj.so >>>>>>>>>> #11 0x00007ffff7101ded in jtdfs1 () from >>>>>>>> /home/ubuntu/j64-801/bin/libj.so >>>>>>>>>> #12 0x00007ffff7145b64 in jtmonad () from >>>>>>>> /home/ubuntu/j64-801/bin/libj.so >>>>>>>>>> #13 0x00007ffff7145669 in jtparsea () from >>>>>>>> /home/ubuntu/j64-801/bin/libj.so >>>>>>>>>> #14 0x00007ffff7132e3e in jtparsex () from >>>>>>>> /home/ubuntu/j64-801/bin/libj.so >>>>>>>>>> #15 0x00007ffff712e750 in jtxdefn () from >>>>>>>> /home/ubuntu/j64-801/bin/libj.so >>>>>>>>>> #16 0x00007ffff7101ded in jtdfs1 () from >>>>>>>> /home/ubuntu/j64-801/bin/libj.so >>>>>>>>>> #17 0x00007ffff7152bca in jtunquote () from >>>>>>>>>> /home/ubuntu/j64-801/bin/libj.so >>>>>>>>>> #18 0x00007ffff7101ded in jtdfs1 () from >>>>>>>> /home/ubuntu/j64-801/bin/libj.so >>>>>>>>>> #19 0x00007ffff7145b64 in jtmonad () from >>>>>>>> /home/ubuntu/j64-801/bin/libj.so >>>>>>>>>> #20 0x00007ffff7145669 in jtparsea () from >>>>>>>> /home/ubuntu/j64-801/bin/libj.so >>>>>>>>>> #21 0x00007ffff7145829 in jtparse () from >>>>>>>> /home/ubuntu/j64-801/bin/libj.so >>>>>>>>>> #22 0x00007ffff7148847 in jtexec1 () from >>>>>>>> /home/ubuntu/j64-801/bin/libj.so >>>>>>>>>> #23 0x00007ffff7281c8c in cb3 () from >>>>>>> /home/ubuntu/j64-801/bin/libj.so >>>>>>>>>> #24 0x00007ffff6a75b11 in ?? () from >>>>>>>> /lib/x86_64-linux-gnu/libexpat.so.1 >>>>>>>>>> #25 0x00007ffff6a7664e in ?? () from >>>>>>>> /lib/x86_64-linux-gnu/libexpat.so.1 >>>>>>>>>> #26 0x00007ffff6a749e1 in ?? () from >>>>>>>> /lib/x86_64-linux-gnu/libexpat.so.1 >>>>>>>>>> #27 0x00007ffff6a7516d in ?? () from >>>>>>>> /lib/x86_64-linux-gnu/libexpat.so.1 >>>>>>>>>> #28 0x00007ffff6a785df in XML_ParseBuffer () from >>>>>>>>>> /lib/x86_64-linux-gnu/libexpat.so.1 >>>>>>>>>> #29 0x00007ffff7287a8d in docall () from >>>>>>>> /home/ubuntu/j64-801/bin/libj.so >>>>>>>>>> #30 0x00007ffff7289899 in jtcdexec1 () from >>>>>>>>>> /home/ubuntu/j64-801/bin/libj.so >>>>>>>>>> #31 0x00007ffff728a1f4 in jtcd () from >>>>>>> /home/ubuntu/j64-801/bin/libj. ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
