Loading ...
Sorry, an error occurred while loading the content.

Re: [jasspa] Segmentation fault in ME2009 in AMD64 Arch (Solution inside)

Expand Messages
  • Jon Green
    ... I think the gcc flag is -m32 for a 32-bit build. There is a problem with the source code which is a bit naughty (ideally solved using a common header) and
    Message 1 of 13 , Oct 5, 2009
    • 0 Attachment
      Steven Phillips wrote:
      >
      >
      > Pedro,
      >
      > Have you built ME as a 64bit app? I.e. is the size of a pointer 8 bytes?
      > If so you are opening a much bigger can of worms - I would be very
      > surprised if this was the only crashing issue!
      >
      > ME is currently only a 32bit app and, as Jon knows, I do not see that
      > changing in a hurry - the concept of needing to edit a 2Gb+ source file
      > seems a very long way for (just not practical) and page-file can be used
      > for very large log files etc.
      >
      > Steve

      I think the gcc flag is -m32 for a 32-bit build.

      There is a problem with the source code which is a bit naughty (ideally solved using a common header) and should be corrected. The easiest fix is below.

      Note I have just built a 64-bit version on Solaris and surprisingly I have not found a problem yet. There must be some in there!

      Regards
      Jon



      cd /home/jon/me091003/src/
      gdiff --context --minimal --ignore-space-change --recursive "/home/jon/merep/me/src/estruct.h" "/home/jon/me091003/src/estruct.h"

      *** /home/jon/merep/me/src/estruct.h 2009-08-29 18:04:28.839308000 +0100
      --- /home/jon/me091003/src/estruct.h 2009-10-05 23:26:58.897105000 +0100
      ***************
      *** 1202,1208 ****
      --- 1202,1211 ----
      * main.c */
      typedef struct meUndoNarrow {
      struct meUndoNode *next ;
      + union {
      meInt dotp ;
      + void * dummy ;
      + } udata ;
      meInt count ;
      meScheme scheme ;
      meUByte type ;
      [EXIT 1]
      cd /home/jon/me091003/src/
      gdiff --context --minimal --ignore-space-change --recursive "/home/jon/merep/me/src/undo.c" "/home/jon/me091003/src/undo.c"

      *** /home/jon/merep/me/src/undo.c 2009-08-29 18:04:29.246002000 +0100
      --- /home/jon/me091003/src/undo.c 2009-10-05 23:29:08.573061000 +0100
      ***************
      *** 385,391 ****
      ((nn = (meUndoNarrow *) meUndoCreateNode(sizeof(meUndoNarrow)+ll)) != NULL))
      {
      nn->type |= meUNDO_SPECIAL|meUNDO_NARROW|meUNDO_NARROW_ADD ;
      ! nn->dotp = sln ;
      nn->count = 0 ;
      nn->name = name ;
      nn->markupCmd = markupCmd ;
      --- 385,391 ----
      ((nn = (meUndoNarrow *) meUndoCreateNode(sizeof(meUndoNarrow)+ll)) != NULL))
      {
      nn->type |= meUNDO_SPECIAL|meUNDO_NARROW|meUNDO_NARROW_ADD ;
      ! nn->udata.dotp = sln ;
      nn->count = 0 ;
      nn->name = name ;
      nn->markupCmd = markupCmd ;
      ***************
      *** 405,411 ****
      ((nn = (meUndoNarrow*) meUndoCreateNode(sizeof(meUndoNarrow)+ll)) != NULL))
      {
      nn->type |= meUNDO_SPECIAL|meUNDO_NARROW ;
      ! nn->dotp = sln ;
      nn->count = eln ;
      nn->name = name ;
      nn->scheme = scheme ;
      --- 405,411 ----
      ((nn = (meUndoNarrow*) meUndoCreateNode(sizeof(meUndoNarrow)+ll)) != NULL))
      {
      nn->type |= meUNDO_SPECIAL|meUNDO_NARROW ;
      ! nn->udata.dotp = sln ;
      nn->count = eln ;
      nn->name = name ;
      nn->scheme = scheme ;
      ***************
      *** 558,564 ****
      meUndoNarrow *nun = (meUndoNarrow *) cun ;
      meInt name ;
      name = nun->name ;
      ! windowGotoLine(meTRUE,nun->dotp+1) ;
      if(nun->type & meUNDO_NARROW_ADD)
      {
      meNarrow *nrrw ;
      --- 558,564 ----
      meUndoNarrow *nun = (meUndoNarrow *) cun ;
      meInt name ;
      name = nun->name ;
      ! windowGotoLine(meTRUE,nun->udata.dotp+1) ;
      if(nun->type & meUNDO_NARROW_ADD)
      {
      meNarrow *nrrw ;
      ***************
      *** 577,583 ****
      slp = frameCur->windowCur->dotLine ;
      windowGotoLine(meTRUE,ccount+1) ;
      meBufferCreateNarrow(frameCur->bufferCur,slp,frameCur->windowCur->dotLine,
      ! nun->dotp,ccount,name,nun->scheme,
      (nun->markupFlag) ? nun->str:NULL,nun->markupCmd,1) ;
      }
      }
      --- 577,583 ----
      slp = frameCur->windowCur->dotLine ;
      windowGotoLine(meTRUE,ccount+1) ;
      meBufferCreateNarrow(frameCur->bufferCur,slp,frameCur->windowCur->dotLine,
      ! nun->udata.dotp,ccount,name,nun->scheme,
      (nun->markupFlag) ? nun->str:NULL,nun->markupCmd,1) ;
      }
      }
      [EXIT 1]

      >
      > azynheira wrote:
      >>
      >>
      >> Hi,
      >> If one tries to use the notes application by pressing F8 or executing
      >> 'notes' in the modeline the application will crash.
      >>
      >> The problem is in the meUndoRemove in the free() call.
      >>
      >> It has to do with the definition of the following structures -
      >> meUndoNode and meUndoNarrow - and the fact the in a AMD64 arch the
      >> pointer size is 8 bytes instead of the usual 4 for a x86 machine,
      >> making the structures to be out of alignment with each-other. This is
      >> verified if I compile without NDEBUG defined, ME crashes in the assert
      >> of line 1250 in main.c.
      >>
      >> This can be easely corrected by either :
      >> 1) Defining meInt typedefs as long(s) in emain.h, making the
      >> structures to be aligned.
      >>
      >> 2) Padding the above mentioned structures in case of compiling for a
      >> 64bit arch.
      >>
      >> I tested the approach 1) and it works, along with some hopefuly
      >> unharful warnings. I used Ubuntu 9.04 AMD64.
      >>
      >> Comments apperciated.
      >> Kind Regards.
      >>
      >> Pedro
      >>
      >
      >
      >
    • azynheira
      Hello All, Yes I did, the first thing I did was check the sizeof of pointers and stuff and its : - 8 bytes for pointers - 8 bytes for longs - 4 bytes for ints
      Message 2 of 13 , Oct 6, 2009
      • 0 Attachment
        Hello All,
        Yes I did, the first thing I did was check the sizeof of pointers and stuff and its :
        - 8 bytes for pointers
        - 8 bytes for longs
        - 4 bytes for ints

        Im using GNU C compiler version (the one bundled with Ubuntu 9.04 - Dont know the version by heart!)

        I have 64bit Ubuntu running on a AMD64 machine that why I compiled it 64bit, otherwise I use it plain 32bit mode (Windows and alike!).

        In the following structs:

        - next match the address
        - count does not because the union is aligned to 8 bytes in a 64bit machine making it unaligned.

        Maybe its only here the problem, if the code does not more of these situations.

        typedef struct meUndoNode {
        struct meUndoNode *next ;
        union {
        meInt dotp ;
        meInt *lineSort ;
        meUndoCoord *pos ;
        } udata ;
        meInt count ;
        meUShort doto ;
        meUByte type ;
        meUByte str[1] ;
        } meUndoNode ;

        typedef struct meUndoNarrow {
        struct meUndoNode *next ;
        meInt dotp ;
        meInt count ;
        meScheme scheme ;
        meUByte type ;
        meUByte markupFlag ;
        meInt name ;
        meInt markupCmd ;
        meUByte str[1] ;
        } meUndoNarrow ;

        Maybe in the Solaris C compiler it makes smart memory algngment in the structs error case and the problem is not there.

        Depends a lot on the compiler. ...
      • azynheira
        Hi All, Sorry but just for completion, I ve been doing a lot of hacking (read programming) in my AMD64 box with the 64bit build and besides the problem
        Message 3 of 13 , Oct 6, 2009
        • 0 Attachment
          Hi All,
          Sorry but just for completion, I've been doing a lot of hacking (read programming) in my AMD64 box with the 64bit build and besides the problem reported, I have not seem any other problem.

          Regards,
          Pedro
        • Steven Phillips
          Pedro & Jon, I would be amazed if this was the only issue, I wrote a lot of the code and at the time every byte saved was important which is why some fields
          Message 4 of 13 , Oct 6, 2009
          • 0 Attachment
            Pedro & Jon,

            I would be amazed if this was the only issue, I wrote a lot of the code and at the time every byte saved was important which is why some fields are overloaded. Problem is that to reduce the warnings they are properly typecast so tracking them down might be a real pain. I suspect spelling would be another problematic area but there could be all sorts lurking.

            Ideally you need to change the compiler warning flags so that it complains about downsizing a pointer to 4 bytes regardless of the typecast and from the warnings compile a list of problematic areas - we can then consider the implications...

            Steve

            azynheira wrote:
             

            Hello All,
            Yes I did, the first thing I did was check the sizeof of pointers and stuff and its :
            - 8 bytes for pointers
            - 8 bytes for longs
            - 4 bytes for ints

            Im using GNU C compiler version (the one bundled with Ubuntu 9.04 - Dont know the version by heart!)

            I have 64bit Ubuntu running on a AMD64 machine that why I compiled it 64bit, otherwise I use it plain 32bit mode (Windows and alike!).

            In the following structs:

            - next match the address
            - count does not because the union is aligned to 8 bytes in a 64bit machine making it unaligned.

            Maybe its only here the problem, if the code does not more of these situations.

            typedef struct meUndoNode {
            struct meUndoNode *next ;
            union {
            meInt dotp ;
            meInt *lineSort ;
            meUndoCoord *pos ;
            } udata ;
            meInt count ;
            meUShort doto ;
            meUByte type ;
            meUByte str[1] ;
            } meUndoNode ;

            typedef struct meUndoNarrow {
            struct meUndoNode *next ;
            meInt dotp ;
            meInt count ;
            meScheme scheme ;
            meUByte type ;
            meUByte markupFlag ;
            meInt name ;
            meInt markupCmd ;
            meUByte str[1] ;
            } meUndoNarrow ;

            Maybe in the Solaris C compiler it makes smart memory algngment in the structs error case and the problem is not there.

            Depends a lot on the compiler. ...

          • azynheira
            Hi All, My proposal is to do as Steve has proposed. I will have to do it on my home PC. Maybe a good idea would be to also pass valgrind over the whole code,
            Message 5 of 13 , Oct 6, 2009
            • 0 Attachment
              Hi All,
              My proposal is to do as Steve has proposed. I will have to do it on my home PC.

              Maybe a good idea would be to also pass valgrind over the whole code, could be that apart from the undo and spell features all other cases are not that much.

              Comments?
              Regards,
              Pedro

              --- In jasspa@yahoogroups.com, Steven Phillips <bill@...> wrote:
              >
              > Pedro & Jon,
              >
              > I would be amazed if this was the only issue, I wrote a lot of the code
              > and at the time every byte saved was important which is why some fields
              > are overloaded. Problem is that to reduce the warnings they are properly
              > typecast so tracking them down might be a real pain. I suspect spelling
              > would be another problematic area but there could be all sorts lurking.
              >
              > Ideally you need to change the compiler warning flags so that it
              > complains about downsizing a pointer to 4 bytes regardless of the
              > typecast and from the warnings compile a list of problematic areas - we
              > can then consider the implications...
              >
              > Steve
              >
              > azynheira wrote:
              > >
              > >
              > > Hello All,
              > > Yes I did, the first thing I did was check the sizeof of pointers and
              > > stuff and its :
              > > - 8 bytes for pointers
              > > - 8 bytes for longs
              > > - 4 bytes for ints
              > >
              > > Im using GNU C compiler version (the one bundled with Ubuntu 9.04 -
              > > Dont know the version by heart!)
              > >
              > > I have 64bit Ubuntu running on a AMD64 machine that why I compiled it
              > > 64bit, otherwise I use it plain 32bit mode (Windows and alike!).
              > >
              > > In the following structs:
              > >
              > > - next match the address
              > > - count does not because the union is aligned to 8 bytes in a 64bit
              > > machine making it unaligned.
              > >
              > > Maybe its only here the problem, if the code does not more of these
              > > situations.
              > >
              > > typedef struct meUndoNode {
              > > struct meUndoNode *next ;
              > > union {
              > > meInt dotp ;
              > > meInt *lineSort ;
              > > meUndoCoord *pos ;
              > > } udata ;
              > > meInt count ;
              > > meUShort doto ;
              > > meUByte type ;
              > > meUByte str[1] ;
              > > } meUndoNode ;
              > >
              > > typedef struct meUndoNarrow {
              > > struct meUndoNode *next ;
              > > meInt dotp ;
              > > meInt count ;
              > > meScheme scheme ;
              > > meUByte type ;
              > > meUByte markupFlag ;
              > > meInt name ;
              > > meInt markupCmd ;
              > > meUByte str[1] ;
              > > } meUndoNarrow ;
              > >
              > > Maybe in the Solaris C compiler it makes smart memory algngment in the
              > > structs error case and the problem is not there.
              > >
              > > Depends a lot on the compiler. ...
              > >
              > >
              >
            • azynheira
              Hi Steven, Yesterday I did some further investigation on this and the Segfault only appears if the notes files needs to be created (you are asked the notes
              Message 6 of 13 , Oct 8, 2009
              • 0 Attachment
                Hi Steven,
                Yesterday I did some further investigation on this and the Segfault only appears if the notes files needs to be created (you are asked the notes files in the OSD). If the notes .enf fil already exist you dont have any problem whatsoever.

                Regards,
                Pedro

                --- In jasspa@yahoogroups.com, Jon Green <jon@...> wrote:
                >
                > Steven Phillips wrote:
                > >
                > >
                > > Pedro,
                > >
                > > Have you built ME as a 64bit app? I.e. is the size of a pointer 8 bytes?
                > > If so you are opening a much bigger can of worms - I would be very
                > > surprised if this was the only crashing issue!
                > >
                > > ME is currently only a 32bit app and, as Jon knows, I do not see that
                > > changing in a hurry - the concept of needing to edit a 2Gb+ source file
                > > seems a very long way for (just not practical) and page-file can be used
                > > for very large log files etc.
                > >
                > > Steve
                >
                > I think the gcc flag is -m32 for a 32-bit build.
                >
                > There is a problem with the source code which is a bit naughty (ideally solved using a common header) and should be corrected. The easiest fix is below.
                >
                > Note I have just built a 64-bit version on Solaris and surprisingly I have not found a problem yet. There must be some in there!
                >
                > Regards
                > Jon
                >
                >
                >
                > cd /home/jon/me091003/src/
                > gdiff --context --minimal --ignore-space-change --recursive "/home/jon/merep/me/src/estruct.h" "/home/jon/me091003/src/estruct.h"
                >
                > *** /home/jon/merep/me/src/estruct.h 2009-08-29 18:04:28.839308000 +0100
                > --- /home/jon/me091003/src/estruct.h 2009-10-05 23:26:58.897105000 +0100
                > ***************
                > *** 1202,1208 ****
                > --- 1202,1211 ----
                > * main.c */
                > typedef struct meUndoNarrow {
                > struct meUndoNode *next ;
                > + union {
                > meInt dotp ;
                > + void * dummy ;
                > + } udata ;
                > meInt count ;
                > meScheme scheme ;
                > meUByte type ;
                > [EXIT 1]
                > cd /home/jon/me091003/src/
                > gdiff --context --minimal --ignore-space-change --recursive "/home/jon/merep/me/src/undo.c" "/home/jon/me091003/src/undo.c"
                >
                > *** /home/jon/merep/me/src/undo.c 2009-08-29 18:04:29.246002000 +0100
                > --- /home/jon/me091003/src/undo.c 2009-10-05 23:29:08.573061000 +0100
                > ***************
                > *** 385,391 ****
                > ((nn = (meUndoNarrow *) meUndoCreateNode(sizeof(meUndoNarrow)+ll)) != NULL))
                > {
                > nn->type |= meUNDO_SPECIAL|meUNDO_NARROW|meUNDO_NARROW_ADD ;
                > ! nn->dotp = sln ;
                > nn->count = 0 ;
                > nn->name = name ;
                > nn->markupCmd = markupCmd ;
                > --- 385,391 ----
                > ((nn = (meUndoNarrow *) meUndoCreateNode(sizeof(meUndoNarrow)+ll)) != NULL))
                > {
                > nn->type |= meUNDO_SPECIAL|meUNDO_NARROW|meUNDO_NARROW_ADD ;
                > ! nn->udata.dotp = sln ;
                > nn->count = 0 ;
                > nn->name = name ;
                > nn->markupCmd = markupCmd ;
                > ***************
                > *** 405,411 ****
                > ((nn = (meUndoNarrow*) meUndoCreateNode(sizeof(meUndoNarrow)+ll)) != NULL))
                > {
                > nn->type |= meUNDO_SPECIAL|meUNDO_NARROW ;
                > ! nn->dotp = sln ;
                > nn->count = eln ;
                > nn->name = name ;
                > nn->scheme = scheme ;
                > --- 405,411 ----
                > ((nn = (meUndoNarrow*) meUndoCreateNode(sizeof(meUndoNarrow)+ll)) != NULL))
                > {
                > nn->type |= meUNDO_SPECIAL|meUNDO_NARROW ;
                > ! nn->udata.dotp = sln ;
                > nn->count = eln ;
                > nn->name = name ;
                > nn->scheme = scheme ;
                > ***************
                > *** 558,564 ****
                > meUndoNarrow *nun = (meUndoNarrow *) cun ;
                > meInt name ;
                > name = nun->name ;
                > ! windowGotoLine(meTRUE,nun->dotp+1) ;
                > if(nun->type & meUNDO_NARROW_ADD)
                > {
                > meNarrow *nrrw ;
                > --- 558,564 ----
                > meUndoNarrow *nun = (meUndoNarrow *) cun ;
                > meInt name ;
                > name = nun->name ;
                > ! windowGotoLine(meTRUE,nun->udata.dotp+1) ;
                > if(nun->type & meUNDO_NARROW_ADD)
                > {
                > meNarrow *nrrw ;
                > ***************
                > *** 577,583 ****
                > slp = frameCur->windowCur->dotLine ;
                > windowGotoLine(meTRUE,ccount+1) ;
                > meBufferCreateNarrow(frameCur->bufferCur,slp,frameCur->windowCur->dotLine,
                > ! nun->dotp,ccount,name,nun->scheme,
                > (nun->markupFlag) ? nun->str:NULL,nun->markupCmd,1) ;
                > }
                > }
                > --- 577,583 ----
                > slp = frameCur->windowCur->dotLine ;
                > windowGotoLine(meTRUE,ccount+1) ;
                > meBufferCreateNarrow(frameCur->bufferCur,slp,frameCur->windowCur->dotLine,
                > ! nun->udata.dotp,ccount,name,nun->scheme,
                > (nun->markupFlag) ? nun->str:NULL,nun->markupCmd,1) ;
                > }
                > }
                > [EXIT 1]
                >
                > >
                > > azynheira wrote:
                > >>
                > >>
                > >> Hi,
                > >> If one tries to use the notes application by pressing F8 or executing
                > >> 'notes' in the modeline the application will crash.
                > >>
                > >> The problem is in the meUndoRemove in the free() call.
                > >>
                > >> It has to do with the definition of the following structures -
                > >> meUndoNode and meUndoNarrow - and the fact the in a AMD64 arch the
                > >> pointer size is 8 bytes instead of the usual 4 for a x86 machine,
                > >> making the structures to be out of alignment with each-other. This is
                > >> verified if I compile without NDEBUG defined, ME crashes in the assert
                > >> of line 1250 in main.c.
                > >>
                > >> This can be easely corrected by either :
                > >> 1) Defining meInt typedefs as long(s) in emain.h, making the
                > >> structures to be aligned.
                > >>
                > >> 2) Padding the above mentioned structures in case of compiling for a
                > >> 64bit arch.
                > >>
                > >> I tested the approach 1) and it works, along with some hopefuly
                > >> unharful warnings. I used Ubuntu 9.04 AMD64.
                > >>
                > >> Comments apperciated.
                > >> Kind Regards.
                > >>
                > >> Pedro
                > >>
                > >
                > >
                > >
                >
              • azynheira
                Hi All, I did some tests on the AMD64 platform redefining typedef signed int meInt ; typedef unsigned int meUInt ; into typedef signed long meInt ;
                Message 7 of 13 , Oct 9, 2009
                • 0 Attachment
                  Hi All,
                  I did some tests on the AMD64 platform redefining
                  typedef signed int meInt ;
                  typedef unsigned int meUInt ;

                  into
                  typedef signed long meInt ;
                  typedef unsigned long meUInt ;

                  And the results were quite good.

                  Undo works and so does the spelling which also broke under the normal compilation.

                  Thoughts on this?

                  Kind Regards,

                  Pedro
                • Jon Green
                  ... I am still wondering why you need to build a 64-bit version? Does a 32-bit version not run? Can you not build with -m32? Jon
                  Message 8 of 13 , Oct 9, 2009
                  • 0 Attachment
                    On Fri 09/10/09 3:38 PM , "azynheira" pedro.gomes@... sent:
                    > Hi All,
                    > I did some tests on the AMD64 platform redefining
                    > typedef signed int meInt ;
                    > typedef unsigned int meUInt ;
                    >
                    > into
                    > typedef signed long meInt ;
                    > typedef unsigned long meUInt ;
                    >
                    > And the results were quite good.
                    >
                    > Undo works and so does the spelling which also broke under the normal
                    > compilation.
                    > Thoughts on this?

                    I am still wondering why you need to build a 64-bit version?
                    Does a 32-bit version not run?
                    Can you not build with -m32?

                    Jon

                    >
                    > Kind Regards,
                    >
                    > Pedro
                    >
                    >
                    >
                    >
                    >
                    >
                    > ------------------------------------
                    >
                    > __________________________________________________________________________
                    > This is an unmoderated list, but new members are moderated to ensure that
                    > there are no spam users. JASSPA is not responsible for the content of any material posted to this list.
                    >
                    > To un-subscribe, send a mail message to
                    >
                    > jasspa-unsubscribe@yahoogroups.com
                    > or visit http://groups.yahoo.com/group/jasspa andmodify your account settings manually.
                    >
                    >
                    > Yahoo! Groups Links
                    >
                    > Individual Email | Traditional
                    >
                    > jasspa-unsubscribe@yahoogroups.com
                    >
                    >
                    ---- Message sent via KC WebMail - http://webmail.mistral.net/
                  • Jon Green
                    ... Hi Pedro, I now understand what you are doing and you have been right to be persistent - we need to fix this. Your assessment was correct that spelling
                    Message 9 of 13 , Oct 10, 2009
                    • 0 Attachment
                      azynheira wrote:
                      > Hi All,
                      > I did some tests on the AMD64 platform redefining
                      > typedef signed int meInt ;
                      > typedef unsigned int meUInt ;
                      >
                      > into
                      > typedef signed long meInt ;
                      > typedef unsigned long meUInt ;
                      >
                      > And the results were quite good.
                      >
                      > Undo works and so does the spelling which also broke under the normal compilation.
                      >
                      > Thoughts on this?
                      >
                      > Kind Regards,
                      >
                      > Pedro
                      >

                      Hi Pedro,

                      I now understand what you are doing and you have been right to be persistent -
                      we need to fix this.

                      Your assessment was correct that spelling broke with a 64-bit compilation (and
                      previously notes). The spelling problem was due to some bad pointer arithmetic.
                      The highlighting looked to be problematic but in fact there was no problem here.

                      I've fixed these issues and it should now build (there are a few integer size
                      warnings but you can ignore these as I have investigated them just cannot get
                      the compiler to get rid of them). You will not need to change the typedef
                      definitions that you have above.

                      The source code bundle is here:

                      http://www.jasspa.com/development/beta_testing/jasspa-mesrc-20091010.tar.gz

                      There is also a pre-built Debian package:

                      http://www.jasspa.com/development/beta_testing/me-jasspa_0.0.20091010_amd64.deb

                      which you can install with:

                      sudo dpkg -i me-jasspa_0.0.20091010_amd64.deb me-jasspa-data_0.0.20091003_all.deb

                      If you are installing the package then pick the macros and spelling dictionary
                      up from:

                      http://www.jasspa.com/release_20090909/debian/jaunty_ubuntu_9.04/me-jasspa-data_0.0.20091003_all.deb
                      http://www.jasspa.com/release_20090909/debian/jaunty_ubuntu_9.04/me-jasspa-ptpt_0.0.20091003_all.deb
                      http://www.jasspa.com/release_20090909/debian/jaunty_ubuntu_9.04/me-jasspa-enus_0.0.20091003_all.deb
                      http://www.jasspa.com/release_20090909/debian/jaunty_ubuntu_9.04/me-jasspa-engb_0.0.20091003_all.deb

                      Hope this solves the issues. If there are any problems then let me know, so far
                      I have not found any more issues.

                      Thanks for your help

                      Regards
                      Jon.
                    • azynheira
                      Hi Jon, I saw the beta testing source and in fact you were much more of an engineer than I was :P. I just picked my big hammer and marched over the whole code
                      Message 10 of 13 , Oct 10, 2009
                      • 0 Attachment
                        Hi Jon,
                        I saw the beta testing source and in fact you were much more of an engineer than I was :P. I just picked my big hammer and marched over the whole code with my patch :-)

                        I will use it from now on and keep you posted on any problems I find ...

                        Thanks,
                        Regards,
                        Pedro

                        > Hi Pedro,
                        >
                        > I now understand what you are doing and you have been right to be persistent -
                        > we need to fix this.
                        >
                        > Your assessment was correct that spelling broke with a 64-bit compilation (and
                        > previously notes). The spelling problem was due to some bad pointer arithmetic.
                        > The highlighting looked to be problematic but in fact there was no problem here.
                        >
                        > I've fixed these issues and it should now build (there are a few integer size
                        > warnings but you can ignore these as I have investigated them just cannot get
                        > the compiler to get rid of them). You will not need to change the typedef
                        > definitions that you have above.
                        >
                        > The source code bundle is here:
                        >
                        > http://www.jasspa.com/development/beta_testing/jasspa-mesrc-20091010.tar.gz
                        >
                        > There is also a pre-built Debian package:
                        >
                        > http://www.jasspa.com/development/beta_testing/me-jasspa_0.0.20091010_amd64.deb
                        >
                        > which you can install with:
                        >
                        > sudo dpkg -i me-jasspa_0.0.20091010_amd64.deb me-jasspa-data_0.0.20091003_all.deb
                        >
                        > If you are installing the package then pick the macros and spelling dictionary
                        > up from:
                        >
                        > http://www.jasspa.com/release_20090909/debian/jaunty_ubuntu_9.04/me-jasspa-data_0.0.20091003_all.deb
                        > http://www.jasspa.com/release_20090909/debian/jaunty_ubuntu_9.04/me-jasspa-ptpt_0.0.20091003_all.deb
                        > http://www.jasspa.com/release_20090909/debian/jaunty_ubuntu_9.04/me-jasspa-enus_0.0.20091003_all.deb
                        > http://www.jasspa.com/release_20090909/debian/jaunty_ubuntu_9.04/me-jasspa-engb_0.0.20091003_all.deb
                        >
                        > Hope this solves the issues. If there are any problems then let me know, so far
                        > I have not found any more issues.
                        >
                        > Thanks for your help
                        >
                        > Regards
                        > Jon.
                        >
                      • Jon Green
                        ... Hi Pedro, The final version is here (2009/10/11) http://www.jasspa.com/release_20090909/debian/ http://www.jasspa.com/release_20090909/rpm/ I have deleted
                        Message 11 of 13 , Oct 12, 2009
                        • 0 Attachment
                          azynheira wrote:
                          > Hi Jon,
                          > I saw the beta testing source and in fact you were much more of an engineer than I was :P. I just picked my big hammer and marched over the whole code with my patch :-)
                          >
                          > I will use it from now on and keep you posted on any problems I find ...
                          >
                          > Thanks,
                          > Regards,
                          > Pedro

                          Hi Pedro,

                          The final version is here (2009/10/11)

                          http://www.jasspa.com/release_20090909/debian/
                          http://www.jasspa.com/release_20090909/rpm/

                          I have deleted the beta_testing directory now.

                          The RPM's are new and follow the same structure as the debian packages i.e. you
                          minimally need packages me-jasspa*.rpm and me-jasspa-data*.rpm

                          Regards
                          Jon

                          >
                          >> Hi Pedro,
                          >>
                          >> I now understand what you are doing and you have been right to be persistent -
                          >> we need to fix this.
                          >>
                          >> Your assessment was correct that spelling broke with a 64-bit compilation (and
                          >> previously notes). The spelling problem was due to some bad pointer arithmetic.
                          >> The highlighting looked to be problematic but in fact there was no problem here.
                          >>
                          >> I've fixed these issues and it should now build (there are a few integer size
                          >> warnings but you can ignore these as I have investigated them just cannot get
                          >> the compiler to get rid of them). You will not need to change the typedef
                          >> definitions that you have above.
                          >>
                          >> The source code bundle is here:
                          >>
                          >> http://www.jasspa.com/development/beta_testing/jasspa-mesrc-20091010.tar.gz
                          >>
                          >> There is also a pre-built Debian package:
                          >>
                          >> http://www.jasspa.com/development/beta_testing/me-jasspa_0.0.20091010_amd64.deb
                          >>
                          >> which you can install with:
                          >>
                          >> sudo dpkg -i me-jasspa_0.0.20091010_amd64.deb me-jasspa-data_0.0.20091003_all.deb
                          >>
                          >> If you are installing the package then pick the macros and spelling dictionary
                          >> up from:
                          >>
                          >> http://www.jasspa.com/release_20090909/debian/jaunty_ubuntu_9.04/me-jasspa-data_0.0.20091003_all.deb
                          >> http://www.jasspa.com/release_20090909/debian/jaunty_ubuntu_9.04/me-jasspa-ptpt_0.0.20091003_all.deb
                          >> http://www.jasspa.com/release_20090909/debian/jaunty_ubuntu_9.04/me-jasspa-enus_0.0.20091003_all.deb
                          >> http://www.jasspa.com/release_20090909/debian/jaunty_ubuntu_9.04/me-jasspa-engb_0.0.20091003_all.deb
                          >>
                          >> Hope this solves the issues. If there are any problems then let me know, so far
                          >> I have not found any more issues.
                          >>
                          >> Thanks for your help
                          >>
                          >> Regards
                          >> Jon.
                          >>
                          >
                          >
                          >
                        Your message has been successfully submitted and would be delivered to recipients shortly.