#2 compiled MEX scripts throw "fatal" error

v1.0_(example)
open
nobody
None
5
2014-06-07
2014-06-05
lodger
No

I was able to compile Maximus BBS on CentOS 6.5, x86_64 with gcc 4.4.7 20120313 (Red Hat 4.4.7-4). There were a few minor changes required to successfully build Maximus with recent (gcc-4.x) compilers, e.g. include statements for <new.h> had to be changed to <new> etc.

After compiling and installing Maximus, I went on to compile all the scripts in the <maximus>/m directory, using MEX. These scripts compile without problems but: once these scripts are run from within Maximus, they throw the following error:

! 05 Jun 09:07:17 MAX MEX: fatal cs:ffffffffffffffff: kill_str: non-global seg
ment

Since I do not have engough knowledge in building compilers with flex / yacc, I can only assume that this issue is related to changes in gcc 4.x compiler directives or optimizations.

The code itself seems to be OK, as Maximus BBS still compiles on an old Debian 3.1 System running gcc-3.3 - there, the error mentioned above does not occur.

Please, please, pleeeease - if anyone more competent than I am could have a look at this issue and (maybe, hopefully) fix it, I'd be very grateful!

There are only a few open-source BBS servers left out there and I really think that Maximus still is a useful program and I'd really like to run it on a modern Linux OS.

Related

Bugs: #2

Discussion

  • Scott Dudley
    Scott Dudley
    2014-06-05

    You might try modifying the error message in mex/vm_run.c to print out the actual value of strptr->segment and run again to see what it contains, and also to set a breakpoint there with gdb and get a backtrace when it happens.

    Offhand, I would try recompiling it with all optimizations disabled and debugging turned on. If that doesn't work, you might also try to compile it as a 32-bit package rather than 64-bit, since it was designed 20 years before 64-bit registers were in vogue. :-)

    A further step would be to try compiling the MEX scripts with a known-good version of the MEX compiler (from your Debian 3.1 build) and running them on the new gcc-compiled version of Maximus, and vice versa, to see if you can isolate the problem to the compiler or the VM. Note that I would only expect this to work if both systems are 32-bit.

     
    • lodger
      lodger
      2014-06-07

      Thanks for the info regarding 32 bit compatibility!! This did do the
      trick and the scrips now compile and run on CentOS 6.5 i686.

      However, I had to do change a few little things in order to have it all
      compile. Especially, the 'sysop_name' and 'sys_name' are no longer
      properly found by mecca. I did do a quick and dirty workaround by
      renaming these labels 'bbs_name' and 'bbs_sysop' which are properly
      parsed by mecca.

      Also, I had to force using yacc instead of bison during compile time, as
      bison will fail to generate a proper mex_tab.h otherwise.

      And in dbase.cc in the btree directory, I had to change the include file name from new.h to new

      So, now it all works, got xinetd and maxcomm running and offering
      Maximus services on port 2323.

      However, how do I run multiple nodes on a Linux system? There's
      runbbs.sh which works fine with one node.

      If you're interested, I can provide diffs for the few changes I made.
      And once again 'thank you' for responding so quick and pointing me in
      the right direction!

       
      Last edit: lodger 2014-06-08
    • I was also wondering about 64-bit registers. It might be worth
      cross-compiling to 32-bit to see what happens. I have never tried to do
      this, but adding -m32 to your CC make var, and installing 32-bit libc,
      headers, etc, would go a long way toward getting you there.

      Oh, and Hi Scott -- nice to see you again.

      Wes

      On 5 June 2014 11:47, Scott Dudley sdudley@users.sf.net wrote:

      You might try modifying the error message in mex/vm_run.c to print out the
      actual value of strptr->segment and run again to see what it contains, and
      also to set a breakpoint there with gdb and get a backtrace when it happens.

      Offhand, I would try recompiling it with all optimizations disabled and
      debugging turned on. If that doesn't work, you might also try to compile it
      as a 32-bit package rather than 64-bit, since it was designed 20 years
      before 64-bit registers were in vogue. :-)

      A further step would be to try compiling the MEX scripts with a known-good
      version of the MEX compiler (from your Debian 3.1 build) and running them
      on the new gcc-compiled version of Maximus, and vice versa, to see if you
      can isolate the problem to the compiler or the VM. Note that I would only
      expect this to work if both systems are 32-bit.


      Status: open
      Group: v1.0_(example)
      Created: Thu Jun 05, 2014 09:21 AM UTC by lodger
      Last Updated: Thu Jun 05, 2014 09:21 AM UTC
      Owner: nobody

      I was able to compile Maximus BBS on CentOS 6.5, x86_64 with gcc 4.4.7
      20120313 (Red Hat 4.4.7-4). There were a few minor changes required to
      successfully build Maximus with recent (gcc-4.x) compilers, e.g. include
      statements for had to be changed to etc.

      After compiling and installing Maximus, I went on to compile all the
      scripts in the /m directory, using MEX. These scripts compile without
      problems but: once these scripts are run from within Maximus, they throw
      the following error:

      ! 05 Jun 09:07:17 MAX MEX: fatal cs:ffffffffffffffff: kill_str: non-global
      seg
      ment

      Since I do not have engough knowledge in building compilers with flex /
      yacc, I can only assume that this issue is related to changes in gcc 4.x
      compiler directives or optimizations.

      The code itself seems to be OK, as Maximus BBS still compiles on an old
      Debian 3.1 System running gcc-3.3 - there, the error mentioned above does
      not occur.

      Please, please, pleeeease - if anyone more competent than I am could have
      a look at this issue and (maybe, hopefully) fix it, I'd be very grateful!

      There are only a few open-source BBS servers left out there and I really
      think that Maximus still is a useful program and I'd really like to run it
      on a modern Linux OS.


      Sent from sourceforge.net because you indicated interest in
      https://sourceforge.net/p/maximus/bugs/2/

      To unsubscribe from further messages, please visit
      https://sourceforge.net/auth/subscriptions/

      --
      Wesley W. Garland
      Director, Product Development
      PageMail, Inc.
      +1 613 542 2787 x 102

       

      Related

      Bugs: #2

  • lodger
    lodger
    2014-06-07

    Thanks for the info regarding 32 bit compatibility!! This did do the
    trick and the scrips now compile and run on CentOS 6.5 i686.

    However, I had to do change a few little things in order to have it all
    compile. Especially, the 'sysop_name' and 'sys_name' are no longer
    properly found by mecca. I did do a quick and dirty workaround by
    renaming these labels 'bbs_name' and 'bbs_sysop' which are properly
    parsed by mecca.

    Also, I had to force using yacc instead of bison during compile time, as
    bison will fail to generate a proper mex_tab.h otherwise.

    And in dbase.cc in the btree directory, I had to change the include file name from new.h to new

    So, now it all works, got xinetd and maxcomm running and offering
    Maximus services on port 2323.

    However, how do I run multiple nodes on a Linux system? There's
    runbbs.sh which works fine with one node.

    If you're interested, I can provide diffs for the few changes I made.
    And once again 'thank you' for responding so quick and pointing me in
    the right direction!

    P.S: Oops, duplicate post - please feel free to remove this one!

     
    Last edit: lodger 2014-06-07