Hi Jürgen,

I have tested renaming a function based on most recent SVN co.

No more stack traces.

Thank You and Best Regards
Hans-Peter


Am 20.04.25 um 18:43 schrieb Dr. Jürgen Sauermann:
Hi Hans-Peter,

it looks like the problem has disappeared in the latest GNU APL version:
*
            )LOAD MT631_DDD.apl
DUMPED 2025-04-20  18:25:18 (GMT+2)
      )SAVE
2025-04-20  18:41:34 (GMT+2)  MT631_DDD
*
Could you please check if the problem persists after a clean build, i.e.
*
make clean all
sudo make install*


Background:
There was a short period after your previous error report where I had to revert to an older cloning scheme (as controlled by Macro *NEW_CLONE* in file *Value.hh*) to fix the problem that you reported. After that period I returned to the new cloning scheme.

The first stack trace below can only occur if the old cloning scheme was in effect on *)SAVE*.
This makes me believe that your interpreter was built during that period.

Best Regards,
Jürgen


On 4/13/25 22:34, Hans-Peter Sorge via Bugs and suggestions for GNU APL wrote:
 Hi,

The Stack Trace is persistent if I try to )SAVE.
)DUMP, )LOAD, )SAVE does not reproduce the trace.

All Variables were )ERASEd

*    )FNS*
ANALYSE_READINGS_UPDATE     ANALYSE_REDINGS_UPDATE  BYTES DTSs    EDIT    H2D     H2I     H2N     H2T     ISK     LO PROCESS     RA  RAl     RAr     REC     REC_CHR REC_CHR_BYTES   RR  SAVE    SV  TEST    ∆∆

/⍝ The two functions //*ANALYSE_READINGS_UPDATE* and *ANALYSE_REDINGS_UPDATE*
⍝ have identical content.
⍝ //*ANALYSE_REDINGS_UPDATE* had A typo! After multiple updates I opened it ⍝ changed the function name to //*ANALYSE_READINGS_UPDATE*//and closed the function
⍝ then )SAVE the WS and getting the Stack Trace.

⍝ Next I )ERASEd /ANALYSE_READINGS_UPDATE - the newly created function./
⍝ Stack Trace again/
*)ERASE ANALYSE_READINGS_UPDATE*
*)DUMP*
2025-04-13  17:04:42 (GMT+2)
*)SAVE*
*** Sub-Value 0xa8d866f0 has two parents.
Child: vid=-1, _val=0x2000000200, _par=11217
Parent 2: vid=699, _val=0xa9bbc1b0_par=-1
Call stack:

----------------------------------------
-- Stack trace at Archive.cc:1129
----------------------------------------
0x7fc10352a30b __libc_start_main
0x7fc10352a248
0x403e80   main
0x5dc75b    Workspace::immediate_execution(bool)
0x46062b     Command::process_line()
0x460807      Command::process_line(UCS_string&, std::ostream*)
0x46164b       Command::do_APL_command(std::ostream&, UCS_string&)
0x4727f7        Command::cmd_SAVE(std::ostream&, UCS_string_vector const&) 0x5de93d         Workspace::save_WS(std::ostream&, LibRef, UCS_string const&, bool) 0x40f370 XML_Saving_Archive::XML_Saving_Archive(std::ostream&, std::ostream&, char const*)
0x4138f7           XML_Saving_Archive::save()
========================================
========================================

 Running )CHECK...
OK      - no stale functions
OK      - no stale values
OK      - no stale indices

==============================================================================
Assertion failed: vvp
in Function:      cmd_CHECK
in file:          Command.cc:797

C/C++ call stack:

----------------------------------------
-- Stack trace at Assert.cc:75
----------------------------------------
0x7fc10352a30b __libc_start_main
0x7fc10352a248
0x403e80   main
0x5dc75b    Workspace::immediate_execution(bool)
0x46062b     Command::process_line()
0x460807      Command::process_line(UCS_string&, std::ostream*)
0x46164b       Command::do_APL_command(std::ostream&, UCS_string&)
0x4727f7        Command::cmd_SAVE(std::ostream&, UCS_string_vector const&) 0x5de93d         Workspace::save_WS(std::ostream&, LibRef, UCS_string const&, bool) 0x40f370 XML_Saving_Archive::XML_Saving_Archive(std::ostream&, std::ostream&, char const*)
0x413955           XML_Saving_Archive::save()
0x46411c            Command::cmd_CHECK(std::ostream&, UCS_string const&)
0x423f1d             do_Assert(char const*, char const*, char const*, int)
========================================
========    ===============================   =

SI stack:


==============================================================================
*** immediate_execution() caught other exception ***

*)FNS*
ANALYSE_REDINGS_UPDATE  BYTES   DTSs    EDIT    H2D     H2I H2N     H2T     ISK     LO  PROCESS     RA  RAl     RAr REC     REC_CHR     REC_CHR_BYTES   RR  SAVE    SV  TEST    ∆∆

/⍝ After erasing the function with just the missing character *"A"* /
⍝ The )SAVE is OK!
*)ERASE ANALYSE_REDINGS_UPDATE
* *)save *
2025-04-13  17:08:21 (GMT+2)  MT631_EEEE

I hope the stack Trace has information to relate the cause to the function renaming. Other than that I have no idea what else might have caused the stack trace.

The attached )DUMPed WS has both  ANALYSE_READINGS_UPDATE and ANALYSE_REDINGS_UPDATE included.  As I mentioned,  )LOAD, )SAVE  will not reproduce the bug. May be some of the content
pops up in the trace.

The attached )SAVEed WS ends in a nirvana.

Best Regards
Hans-Peter



Reply via email to