TextEdit widget Issue

[wctltya]

Hi Joel and Inmarket,

Almost an year ago I've reported this issue, but perhaps with very bad and complicated explanation and I didn't get support on it.

So, today I dig more into and debug it a bit. I'll try to describe the issue and my findings shortly and as clear as possible:

 I have 3 textedit widgets, each into its own container(together with two labels), but all of them are in a common parent container. All textedits widgets are restricted to 4 chars max. But we can focus on two edit box only. Lets name them TE_1 and TE_2.

Adding max 4 chars in TE_1 is not a problem, unless at least one char is added in TE_2, then I can't add 4th char in TE_1. I'm restricting explanation to TE_1, because even it is the same for TE_2 related to TE_1 its getting more complicated...

Please see the attached video file. 

Debugging the issue, shows that the TextEditAddChars(...) in line 74 invokes gfxRealloc(...) , which returns 0 in line 139, which leads to TextEdditAddChars returns FALSE in line 75.

The particular parameters (filmed in the attached video)  passed to gfxRealloc are pointer to "111", oldsize is 4 and size is 5. Perhaps old size and size includes the NULL terminator, otherwise they should be 3 and 4, I think. But this doesn't cause the issue, as long as the same values are passed when it works, i.e. when TE_2 is empty.

The link to my previous report describing that issue is here(see the last post) 

 

[inmarket]

The fact that gfxReAlloc is returning 0 is the problem. We really asking the operating system to increase the size of the allocation and it is failing.

So, what operating system are you using? Do you have enough free memory available for your allocator to be able to expand the size of the memory block?

[wctltya]

The quote from previous report of the same issue:

"

Thank you inmarket,

Just FYI - I'm running RAW32. The uC is Cortex-M4 with plenty of resources (Flash, RAM, FPU). The project is under KDS (single file including) with GCC compiler and the relevant gfxconf are: 

#define GFX_USE_OS_RAW32    TRUE
#define GFX_COMPILER        GFX_COMPILER_GCC
#define GFX_CPU             GFX_CPU_CORTEX_M4_FP
#define CORTEX_USE_FPU      TRUE
#define GFX_EMULATE_MALLOC  FALSE

And the heap size is set accordingly. I was wondering if the compiler shall be set to GFX_COMPILER_ARMCC? Please, let me know, if I shall turn on/off some other keys..  

"

Except the compiler definition, which I've removed according to your advice Inmarket. 

In addition:

#define GFX_CPU_ENDIAN                           GFX_CPU_ENDIAN_UNKNOWN
#define GOS_RAW_HEAP_SIZE                    61440UL     //RAW32 relevant
#define GFX_OS_HEAP_SIZE                        61440UL 
#define GFX_OS_NO_INIT                              TRUE

Please, let me know if I've to change something.

Edited July 5, 2018 by wctltya

[wctltya]

Hi again,

I found what actually is causing the issue, I think and it is

28 minutes ago, wctltya said:

#define GFX_OS_HEAP_SIZE                        61440UL 

Although I've RAW32 defined and relevant heap size as well, seems that another 60k are booked for OS, which I don't use.

Since I didn't expect this, and because it is something left just from the beginning of the project, I haven't look into the linker output for. Now I can see it. 

Joel and inmarket, definitely it's my mistake. But a common detailed description of the all keys in gfxconf with their relations etc., will help us to avoid such mistakes, I think.

For example I've removed 

41 minutes ago, wctltya said:

#define GFX_OS_NO_INIT                              TRUE

as well, supposing (now) it is not relevant to RAW32 too?

Do you think a regression test is needed now? I'm afraid it is too complicated and will take a lot of time, because the project is in a very advanced stage.  

[inmarket]

GFX_OS_NO_INIT should definitely not be true for RAW32.

You will not need to define the compiler or the endianness unless our autodetect gets it wrong in which case let us know so we can fix the autodetect.

With RAW32 the specified heap size is declared as a static byte array of that size which the RAW32 memory management calls then carve up to satisfy memory requests. Given the above settings being correct there are some possible problems...

1. The specified size is too small for what you are trying to allocate and you are just running out of memory.

2. The specified size is too big and your stack is growing down into the top of the memory array thereby corrupting it.

3. There is a bug in gfxRealloc. This we consider unlikely as the code has been well tested but it is not impossible.

[wctltya]

@inmarket

On 05/07/2018 at 22:58, inmarket said:

3. There is a bug in gfxRealloc. This we consider unlikely as the code has been well tested but it is not impossible.

Definitely there is a bug and it is obvious, I think. See line 138 in gos_x_heap.c:

if (pfree)
	return 0;

 Should be

if (!pfree)
	return 0;

And this fixes the issue.

[inmarket]

This has now been fixed in the repository. Thanks for finding it!