Tag Archives: stack

Initialization of bean failed； nested exception is java.lang.StackOverflowError

Too many assemblies in mybatis spring mapper cause stackoverflow

It is applicable to idea starting a new SSM project
environment Tomcat deployment
reason: the space size of Tomcat catalina.sh is not configured

terms of settlement

1. Modify the catalina.sh file of Tomcat

Directory: Apache Tomcat \ bin \ Catalina. Sh
self allocated space size
Directory: JDK \ 1.8 \ JRE \ lib \ AMD64 \ JVM. CFG
self allocated space size

2. Easy: modify the current project configuration of idea

two point one

Generally, 2100 variables are enough

  Tomcat startup space configuration

 

-Xms512m -Xmx512m -Xss2m -XX:PermSize=512m -XX:MaxPermSize=1024m

Restart to solve the problem

I am the second configuration. Because there is a configured space allocation on the server, my locally developed tester is simply configured on the idea.

[Solved] Leetcode Error: AddressSanitizer: SEGV on unknown address 0x55eb765425b8 (pc 0x55eb76542b86 bp 0x7ffd1bd2

Hi, I’ve come back to the article ᕕ (ᐛ) ᕗ
recently, I’m brushing leetcode, and there’s an error report about stack

 AddressSanitizer:DEADLYSIGNAL
=================================================================
==42==ERROR: AddressSanitizer: SEGV on unknown address 0x55eb765425b8 (pc 0x55eb76542b86 bp 0x7ffd1bd27d50 sp 0x7ffd1bd27d00 T0)
==42==The signal is caused by a WRITE memory access.
    #2 0x7fe2bd0fe0b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2)
AddressSanitizer can not provide additional info.
==42==ABORTING

My code is as follows



bool isValid(char * s){
    bool answer;
    int i=0;
    char tem;
    stack S=creatstack;  //Something is wrong here, it should be a function but I forgot to add the brackets
    while(s[i]!='\0'){
        if(s[i]=='('||s[i]=='['||s[i]=='{') push(s[i],S);
        else{
            tem=pop(S);
            if((tem=='('&&s[i]==')')||(tem=='['&&s[i]==']')||(tem=='{'&&s[i]=='}')) ;
            else return false;
        }
        i++;
    }
    return true;
}

Change to

stack S=creatstack();

After that, the problem was solved

(Keil MDK) UCOS floating point support abnormal solution

Recently, we encountered a problem, that is, the printf display of floating-point calls in uCOSII is abnormal, but the support for floating-point calls on bare metal machines is normal. Here are the details.

When calling printf to debug floating-point numbers in UCOS, it is correct in memory, but print data is 0, and other shaping data are normal.

The running result on bare metal is completely normal, that is to say, the problem lies in UCOS.

According to the information, this is because the user task stack is not aligned with octets. When running bare metal programs, the system’s default stack octets are aligned, but UCOS’s user task stack is not.

Align the user stack octets.

 

Solution:

1. Solutions under IAR: (untested)

Through # pragma data_ Alignment specifies the number of bytes to align

For example:


#pragma data_alignment=8

OS_STK Task1_LED1_Stk[Task1_LED1_Stk_Size];

#pragma data_alignment=8

OS_STK T

2. Solutions under keil MDK: (available for personal testing)

Add the force octet alignment command before the task stack declaration, as follows:

__align(8) static OS_STK  TaskEquipmentStk[TASK_EQUIPMENT_STK_SIZE];
__align(8) static OS_STK  TaskUartRcvStk[TASK_UARTRCV_STK_SIZE];
__align(8) static OS_STK  TaskFileRcvStk[TASK_FILERCV_STK_SIZE];
__align(8) static OS_STK  TaskFtpStk[ TASK_FTP_STK_SIZE ];
__align(8) static OS_STK  TaskErrorRateRS485Stk[ TASK_ERROR_RATE_RS485_STK_SIZE ];

 

Detailed explanation of the reasons

The history of this is that arm itself does not support non aligned data access; Therefore, with a 64bit data operation instruction, the instruction requires 8-byte alignment.

Furthermore, after a certain version of the compiler (rvct3?) AAPCs requires stack 8-byte alignment.

AAPCs with 8-byte alignment first, then cm3. Pay attention to the sequence. Before cm3 r2p0, automatic stack pressing does not require 8 alignment, and r2p0 seems to be forced alignment.

Printf’s 8-alignment is required by the C runtime and has nothing to do with hardware. The C RTL manual is written and can be read. Its root lies in the requirements of AAPCs; AAPCs is rooted in instructions like LDRD.

In other words, in the future, if 128bit data operation is available and arm does not support non alignment, AAPCs may be upgraded to 16 byte alignment.