Crash when clicking on RAM tab on MCU monitor for ATTiny84
Quote from andi8086 on September 29, 2024, 9:15 pmHi,
I cannot debug my program since I cannot view the RAM contents. As soon as I click onto the RAM tab, SimulIDE crashes.
Version 1.1.0-SR0, compiler gcc 14.1.1
usr/include/c++/14.1.1/bits/stl_vector.h:1130: std::vector<_Tp, _Alloc>::reference std::vector<_Tp, _Alloc>::
operator[](size_type) [with _Tp = unsigned char; _Alloc = std::allocator<unsigned char>; reference = unsigned
char&; size_type = long unsigned int]: Assertion '__n < this->size()' failed.
[1] 3955641 IOT instruction (core dumped) simulide
Hi,
I cannot debug my program since I cannot view the RAM contents. As soon as I click onto the RAM tab, SimulIDE crashes.
Version 1.1.0-SR0, compiler gcc 14.1.1
usr/include/c++/14.1.1/bits/stl_vector.h:1130: std::vector<_Tp, _Alloc>::reference std::vector<_Tp, _Alloc>::
operator[](size_type) [with _Tp = unsigned char; _Alloc = std::allocator<unsigned char>; reference = unsigned
char&; size_type = long unsigned int]: Assertion '__n < this->size()' failed.
[1] 3955641 IOT instruction (core dumped) simulide
Quote from arcachofo on September 29, 2024, 9:38 pmHi.
I can't reproduce the issue.
Do you get any error messages at the panel below the circuit when you open it?
Hi.
I can't reproduce the issue.
Do you get any error messages at the panel below the circuit when you open it?
Quote from andi8086 on September 29, 2024, 10:04 pmNone... I just installed the debug version and can you provide a stack trace:
Thread 1 "simulide" received signal SIGABRT, Aborted. 0x00007ffff62a8e44 in ?? () from /usr/lib/libc.so.6 (gdb) bt #0 0x00007ffff62a8e44 in ??? () at /usr/lib/libc.so.6 #1 0x00007ffff6250a30 in raise () at /usr/lib/libc.so.6 #2 0x00007ffff62384c3 in abort () at /usr/lib/libc.so.6 #3 0x00007ffff64d2d60 in std::__glibcxx_assert_fail (file=file@entry=0x8020e8 "/usr/include/c++/14.1.1/bits/stl_vector.h", line=line@entry=1130, function=function@entry=0x802010 "std::vector<_Tp, _Alloc>::reference std::vector<_Tp, _Alloc>::operator[](size_type) [with _Tp = unsigned char; _Alloc = std::allocator<unsigned char>; reference = unsigned char&; size_type = long unsi"..., condition=condition@entry=0x7f75ef "__n < this->size()") at /usr/src/debug/gcc/gcc/libstdc++-v3/src/c++11/assert_fail.cc:41 #4 0x00000000004ea250 in std::vector<unsigned char, std::allocator<unsigned char> >::operator[] (this=<optimized out>, __n=<optimized out>) at /usr/include/c++/14.1.1/bits/stl_vector.h:1128 #5 std::vector<unsigned char, std::allocator<unsigned char> >::operator[] (this=<optimized out>, __n=<optimized out>, this=<optimized out>, __n=<optimized out>) at /usr/include/c++/14.1.1/bits/stl_vector.h:1128 #6 DataSpace::readReg (this=0x13ba600, addr=65535) at ../src/microsim/mcudataspace.cpp:52 #7 0x000000000063c1e9 in DataSpace::getRamValue (this=<optimized out>, address=34) at /usr/include/c++/14.1.1/bits/stl_vector.h:1130 #8 MCUMonitor::updateStep (this=0x12ec2b0) at ../src/gui/memory/mcumonitor.cpp:144 #9 0x00007ffff6ac8b63 in ??? () at /usr/lib/libQt5Core.so.5 #10 0x00007ffff7b290e3 in QTabWidget::currentChanged(int) () at /usr/lib/libQt5Widgets.so.5 #11 0x00007ffff6ac8b63 in ??? () at /usr/lib/libQt5Core.so.5 #12 0x00007ffff7b0af33 in QTabBar::currentChanged(int) () at /usr/lib/libQt5Widgets.so.5 #13 0x00007ffff7b13e06 in QTabBar::mousePressEvent(QMouseEvent*) () at /usr/lib/libQt5Widgets.so.5
So getRamValue is called with address = 34, which then calls readReg with addr 65535 and this seems to be out of range...
Also I read around in the code and found strange things like
mcudataspace.cpp 101 uint8_t DataSpace::getRamValue( int address ) // Read RAM from Mcu Monitor 102 { 103 m_isCpuRead = false; 104 return readReg( getMapperAddr(address) ); 105 m_isCpuRead = true; 106 }
What do you think this last statement will do after a return 😀
Back to the problem: How is the array initialized? I cannot find the spot... and why does getRamValue call readReg, I mean the address of the RAM is clearly more than an uint16, since RAM begins at 0x800060 and should be 512 in size, so clearly 65535 is out of range.
None... I just installed the debug version and can you provide a stack trace:
Thread 1 "simulide" received signal SIGABRT, Aborted.
0x00007ffff62a8e44 in ?? () from /usr/lib/libc.so.6
(gdb) bt
#0 0x00007ffff62a8e44 in ??? () at /usr/lib/libc.so.6
#1 0x00007ffff6250a30 in raise () at /usr/lib/libc.so.6
#2 0x00007ffff62384c3 in abort () at /usr/lib/libc.so.6
#3 0x00007ffff64d2d60 in std::__glibcxx_assert_fail
(file=file@entry=0x8020e8 "/usr/include/c++/14.1.1/bits/stl_vector.h", line=line@entry=1130, function=function@entry=0x802010 "std::vector<_Tp, _Alloc>::reference std::vector<_Tp, _Alloc>::operator[](size_type) [with _Tp = unsigned char; _Alloc = std::allocator<unsigned char>; reference = unsigned char&; size_type = long unsi"..., condition=condition@entry=0x7f75ef "__n < this->size()")
at /usr/src/debug/gcc/gcc/libstdc++-v3/src/c++11/assert_fail.cc:41
#4 0x00000000004ea250 in std::vector<unsigned char, std::allocator<unsigned char> >::operator[]
(this=<optimized out>, __n=<optimized out>) at /usr/include/c++/14.1.1/bits/stl_vector.h:1128
#5 std::vector<unsigned char, std::allocator<unsigned char> >::operator[]
(this=<optimized out>, __n=<optimized out>, this=<optimized out>, __n=<optimized out>)
at /usr/include/c++/14.1.1/bits/stl_vector.h:1128
#6 DataSpace::readReg (this=0x13ba600, addr=65535) at ../src/microsim/mcudataspace.cpp:52
#7 0x000000000063c1e9 in DataSpace::getRamValue (this=<optimized out>, address=34)
at /usr/include/c++/14.1.1/bits/stl_vector.h:1130
#8 MCUMonitor::updateStep (this=0x12ec2b0) at ../src/gui/memory/mcumonitor.cpp:144
#9 0x00007ffff6ac8b63 in ??? () at /usr/lib/libQt5Core.so.5
#10 0x00007ffff7b290e3 in QTabWidget::currentChanged(int) () at /usr/lib/libQt5Widgets.so.5
#11 0x00007ffff6ac8b63 in ??? () at /usr/lib/libQt5Core.so.5
#12 0x00007ffff7b0af33 in QTabBar::currentChanged(int) () at /usr/lib/libQt5Widgets.so.5
#13 0x00007ffff7b13e06 in QTabBar::mousePressEvent(QMouseEvent*) () at /usr/lib/libQt5Widgets.so.5
So getRamValue is called with address = 34, which then calls readReg with addr 65535 and this seems to be out of range...
Also I read around in the code and found strange things like
mcudataspace.cpp
101 uint8_t DataSpace::getRamValue( int address ) // Read RAM from Mcu Monitor
102 {
103 m_isCpuRead = false;
104 return readReg( getMapperAddr(address) );
105 m_isCpuRead = true;
106 }
What do you think this last statement will do after a return 😀
Back to the problem: How is the array initialized? I cannot find the spot... and why does getRamValue call readReg, I mean the address of the RAM is clearly more than an uint16, since RAM begins at 0x800060 and should be 512 in size, so clearly 65535 is out of range.
Quote from arcachofo on September 29, 2024, 10:16 pmAlso I read around in the code and found strange things like
mcudataspace.cpp 101 uint8_t DataSpace::getRamValue( int address ) // Read RAM from Mcu Monitor 102 { 103 m_isCpuRead = false; 104 return readReg( getMapperAddr(address) ); 105 m_isCpuRead = true; 106 }
What do you think this last statement will do after a return 😀
That error was solved some time ago.
Better update your source code.About the crash:
Do you have the "data" folder in the same folder than simulide executable?
Also I read around in the code and found strange things like
mcudataspace.cpp 101 uint8_t DataSpace::getRamValue( int address ) // Read RAM from Mcu Monitor 102 { 103 m_isCpuRead = false; 104 return readReg( getMapperAddr(address) ); 105 m_isCpuRead = true; 106 }
What do you think this last statement will do after a return 😀
That error was solved some time ago.
Better update your source code.
About the crash:
Do you have the "data" folder in the same folder than simulide executable?
Quote from andi8086 on September 29, 2024, 11:41 pmIt seems I have to file a bug with Arch Linux, not here... I just downloaded the precompiled version (which I actually dislike, but gave it a try) and it worked with the RAM tab.
Thanks so far!
It seems I have to file a bug with Arch Linux, not here... I just downloaded the precompiled version (which I actually dislike, but gave it a try) and it worked with the RAM tab.
Thanks so far!
Quote from arcachofo on September 29, 2024, 11:56 pmOk, but maybe we could find the problem.
There is a chance that it is a problem in the code, but I think the most problable cause is some configuration file.
For example /usr/share/simulide/data/AVR/tiny84.mcu is the most likely candidate.<mcu name="tiny84" core="AVR" data="608" prog="4096" progword="2" eeprom="512" inst_cycle="1" freq="16000000" > <include file="avr/avr_gpr.xml" /> <include file="tinyx4/tinyx4_regs.xml" /> <datablock name="RAM" start="0x0060" end="0x025F"/> <!-- Have a look at this line --> <include file="tinyx4/tinyx4_int.xml" /> <include file="tinyx4/tinyx4_perif.xml" /> </mcu>
Ok, but maybe we could find the problem.
There is a chance that it is a problem in the code, but I think the most problable cause is some configuration file.
For example /usr/share/simulide/data/AVR/tiny84.mcu is the most likely candidate.
<mcu name="tiny84" core="AVR" data="608" prog="4096" progword="2" eeprom="512"
inst_cycle="1" freq="16000000" >
<include file="avr/avr_gpr.xml" />
<include file="tinyx4/tinyx4_regs.xml" />
<datablock name="RAM" start="0x0060" end="0x025F"/> <!-- Have a look at this line -->
<include file="tinyx4/tinyx4_int.xml" />
<include file="tinyx4/tinyx4_perif.xml" />
</mcu>
Quote from arcachofo on September 30, 2024, 12:05 amWait... the address was 34, then maybe /usr/share/simulide/data/AVR/tinyx4/tinyx4_regs.xml
<parts> <regblock name="I/O_REG" start="0x0020" end="0x005F" offset="32">
Wait... the address was 34, then maybe /usr/share/simulide/data/AVR/tinyx4/tinyx4_regs.xml
<parts>
<regblock name="I/O_REG" start="0x0020" end="0x005F" offset="32">
Quote from andi8086 on September 30, 2024, 12:39 amJust tried your 2nd post, and changed 'end' to "0x025F", which also crashed. But since it works in the current precompiled version, it might also have been fixed in the code and/or data files - so unlikely we need to debug, especially when you can't reproduce it with newer 1.1 release either.
What is the link to the current source? Maybe I can compare tomorrow. Please don't tell me you use SVN...
Just tried your 2nd post, and changed 'end' to "0x025F", which also crashed. But since it works in the current precompiled version, it might also have been fixed in the code and/or data files - so unlikely we need to debug, especially when you can't reproduce it with newer 1.1 release either.
What is the link to the current source? Maybe I can compare tomorrow. Please don't tell me you use SVN...
Quote from arcachofo on September 30, 2024, 6:03 pmJust tried your 2nd post, and changed 'end' to "0x025F", which also crashed. But since it works in the current precompiled version, it might also have been fixed in the code and/or data files - so unlikely we need to debug, especially when you can't reproduce it with newer 1.1 release either.
From that I guess that the values in your files are the same than in my post (correct ones).
This is really weird, because the source code is the same for all devices.
Everything is created from the data in configuration files, so if the problem only happens with one device, the mosk likely reason is an error in some of these files.
It would be good to see if it also happens for Attiny24 and Attiny44, which are basically the same.Also, not sure about which sources is Arch Linux using.
From here: https://aur.archlinux.org/packages/simulide it seems that it is using 1.1.0-SR0 at Rev 1913.
You can get the source code for that exact revision here: https://bazaar.launchpad.net/~arcachofo/simulide/1.1.0/tarball/1913
For me everything seems ok at that revision.Source code for 1.1.0 is in Launchpad: https://launchpad.net/simulide
Just tried your 2nd post, and changed 'end' to "0x025F", which also crashed. But since it works in the current precompiled version, it might also have been fixed in the code and/or data files - so unlikely we need to debug, especially when you can't reproduce it with newer 1.1 release either.
From that I guess that the values in your files are the same than in my post (correct ones).
This is really weird, because the source code is the same for all devices.
Everything is created from the data in configuration files, so if the problem only happens with one device, the mosk likely reason is an error in some of these files.
It would be good to see if it also happens for Attiny24 and Attiny44, which are basically the same.
Also, not sure about which sources is Arch Linux using.
From here: https://aur.archlinux.org/packages/simulide it seems that it is using 1.1.0-SR0 at Rev 1913.
You can get the source code for that exact revision here: https://bazaar.launchpad.net/~arcachofo/simulide/1.1.0/tarball/1913
For me everything seems ok at that revision.
Source code for 1.1.0 is in Launchpad: https://launchpad.net/simulide