One last point. In the case of Debian. You do not really have to worry much about how large your stack size for any application is. So complicating an application by dynamically allocating memory( heap versus stack ) is not necessarily needed.
Anyway, I'm not 100% sure all Linux distro's behave in this manner, but know for a fact this is the case with Debian as I spent a good amount of time reading / researching this for a project of mine. Not only that, but it is of course possible to structure code in a way that your stack stays small to begin with. Either way, Debian can if needed allocate up to 100% system for a single applications stack if needed. Of course the only way this will ever happen is if tested with specific code . . . On Wed, Mar 9, 2016 at 5:38 AM, William Hermans <[email protected]> wrote: > However . . since *you* do not get to respond to something and then just > tell me to stop talking . . . > > *In C variable[0] is essentially a pointer to the start of variable.* > *No, that's plain wrong. * > > Bullshit. > > *Also to nickpick even more. memset() expects type unsigned character, and >> uint8_t *, and unsigned char * are not really equivalent . . . which is a >> source of even more errors ;) *This* I've had personal hands on with ;)* >> *No, glibc, uclibc, eglibc, even avr-libc all have the same signature, >> which is the following:* >> * void *memset(void *s, int c, size_t n);* >> > > Here I mispoke ( mis-wrote ) but I was not speaking to the function > prototype. But instead the value that memset() "sets" is interpreted as > unsigned char *. So, mixing uint8_t *, and unsigned char * is bad mojo. > It'll work, until you expect it to, and then your code will start randomly > misbehaving. That is to say that such code may / may not work as expected, > or in other words. undefined behavior. I am not however sure if there is in > fact anything in the standard regarding that, but I do know from first hand > experience that such code, that is not consistent in types, is not 100% > reliable. Which is a good reason to use compiler options -Wall, and such. > > @Radek > > *It is just a good engineering practice, to write always free for every >> malloc, in case somebody later on modifies/extends code later on to avoid >> memory-leaks within the program.* >> > > There would be no memory leak. knowing what your code does is in fact good > engineering, so omitting useless code because you know it's useless is not > bad form. It's known as knowing what you're doing ;) > > Anyway, I'm not sure how useful this "test code" really is. This is not > something any useful application would ever do . . .other than apparently > making a beaglebone in certain situations "flicker" . . . > > > On Wed, Mar 9, 2016 at 1:56 AM, <[email protected]> wrote: > >> Hi William, >> >> I would like to point out, that free will never even be reached as there >> is an ifinite loop before it :) >> >> It is just a good engineering practice, to write always free for every >> malloc, in case somebody later on modifies/extends code later on to avoid >> memory-leaks within the program. >> >> Thanks, >> Radek >> >> On Wednesday, March 9, 2016 at 2:29:27 AM UTC+1, William Hermans wrote: >>> >>> I would also like to point out that the free() after the loop ( end of >>> program ) is not necessary. Modern Linux versions deal with this >>> automatically. I do not suppose it'll hurt, but figured I'd point that out. >>> >>> On Tue, Mar 8, 2016 at 6:23 PM, William Hermans <[email protected]> >>> wrote: >>> >>>> *Because it's not calling malloc() over and over...* >>>>> >>>> >>>> Yeap, you're right it's calling memset() every loop. Not sure why I was >>>> thinking it was calling malloc() every loop. But the point is, it does not >>>> matter what is being called in the loop. any system / API call in the loop, >>>> without some form of a sleep() will eat up a lot of CPU cycles. Again, as >>>> much as the system will allow it to, which is usually in the mid to high >>>> 90%'s . . . >>>> >>>> I'm surprised that code would compile at all without a compiler error. >>>>> As &variable[0] probably is not what you think it is. >>>>> >>>> I see no issue here. Can you elaborate? >>>> >>>> So, &variable <- beginning of an array, equivalent to variable[0], but >>>> what is &variable[0] ? A multi dimensional array ? that's not what was >>>> defined . . . to be 100% honest I'm not sure what it does, but the first >>>> thing that comes to mind is "undefined behavior". >>>> >>>> >>>> On Tue, Mar 8, 2016 at 5:39 PM, <[email protected]> wrote: >>>> >>>>> I'm surprised that code would compile at all without a compiler error. >>>>>> As &variable[0] probably is not what you think it is. >>>>>> >>>>> I see no issue here. Can you elaborate? >>>>> >>>>> >>>>>> Also, for the record, infinitely allocating an arbitrary amount of >>>>>> dynamic memory, in a loop, without any kind of a pause is going to eat up >>>>>> an incredible amount of CPU cycles. As in that code will very likely use >>>>>> as >>>>>> close to 100% CPU as the system will allow it. Which again, is no wonder >>>>>> you're "flickering" . . . >>>>>> >>>>> The code is not allocating anything in a loop. >>>>> >>>>> >>>>>> You lucky your program does not randomly crash for using malloc() on >>>>>> the same dynamic memory over, and over, without using free(), or instead >>>>>> using realloc() . . . >>>>>> >>>>> Because it's not calling malloc() over and over... >>>>> >>>>> >>>>> The issue here is that if you run memset() in a tight loop (which at >>>>> least one gstreamer1.6 audio decoder plugins does), it seems to clog up >>>>> the >>>>> data bus enough for the DMA to fail. >>>>> >>>>> >>>>> >>>>>> On Tue, Mar 8, 2016 at 10:16 AM, Radek Dostál <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> Hi Michael, >>>>>>> >>>>>>> we had very similar issue, which we encountered when updating to >>>>>>> gstreamer 1.6. Using git bisect we were able to find a root cause and >>>>>>> prepare simple test program, which reliably reproduces the issue: >>>>>>> >>>>>>> #include <string.h> >>>>>>> #include <stdint.h> >>>>>>> #include <stdlib.h> >>>>>>> >>>>>>> int main(int argc, char **argv) >>>>>>> { >>>>>>> int size; >>>>>>> uint8_t *memblock; >>>>>>> >>>>>>> if (argc < 2) >>>>>>> return -1; >>>>>>> >>>>>>> size = atoi(argv[1]); >>>>>>> >>>>>>> memblock = malloc(size); >>>>>>> >>>>>>> while (1) >>>>>>> { >>>>>>> memset(&memblock[0], 0, size); >>>>>>> } >>>>>>> >>>>>>> free(memblock); >>>>>>> >>>>>>> return 0; >>>>>>> } >>>>>>> >>>>>>> starting this program will cause crazy flickering, ... >>>>>>> >>>>>>> We were able to reproduce the issue with >>>>>>> >>>>>>> 1) debian originally provided on beaglebone using memtest utility >>>>>>> for carlos. Kernel version was: >>>>>>> >>>>>>> Linux version 3.8.13-bone70 (root@a5-imx6q-wandboard-2gb) (gcc >>>>>>> version 4.6.3 (Debian 4.6.3-14) ) #1 SMP Fri Jan 23 02:15:42 UTC 2015 >>>>>>> >>>>>>> 2) latest version of debian from beaglebone website Kernel version >>>>>>> was: >>>>>>> >>>>>>> Linux version 4.1.15-ti-rt-r43 (root@a4-imx6q-wandboard-2gb) (gcc >>>>>>> version 4.9.2 (Debian 4.9.2-10) ) #1 SMP PREEMPT RT Thu Jan 21 20:13:58 >>>>>>> UTC >>>>>>> 2016 >>>>>>> >>>>>>> so it seems to be existing for ages. >>>>>>> >>>>>>> Did you in the mean time managed to find a solution for your problem? >>>>>>> >>>>>>> Thanks, >>>>>>> Radek >>>>>>> >>>>>>> On Monday, February 8, 2016 at 1:18:50 PM UTC+1, Michael Liesenberg >>>>>>> wrote: >>>>>>>> >>>>>>>> Hi there, >>>>>>>> >>>>>>>> >>>>>>>> i was able to get my 10.1 custom Display to work with the RGB Pins >>>>>>>> on the beaglebone black. >>>>>>>> >>>>>>>> I am using the latest Debian Jessie image from beagleboard.org and >>>>>>>> the X11 Desktop has the right colors and the right size. >>>>>>>> >>>>>>>> So i assume that the Timings from my display are correct. >>>>>>>> >>>>>>>> >>>>>>>> panel { >>>>>>>> >>>>>>>> status = "okay"; >>>>>>>> >>>>>>>> compatible = "ti,tilcdc,panel"; >>>>>>>> >>>>>>>> pinctrl-names = "default"; >>>>>>>> >>>>>>>> pinctrl-0 = <&bb_lcd_lcd_pins>; >>>>>>>> >>>>>>>> panel-info { >>>>>>>> >>>>>>>> ac-bias = <255>; >>>>>>>> >>>>>>>> ac-bias-intrpt = <0>; >>>>>>>> >>>>>>>> dma-burst-sz = <16>; >>>>>>>> >>>>>>>> bpp = <32>; >>>>>>>> >>>>>>>> fdd = <0x80>; >>>>>>>> >>>>>>>> tft-alt-mode = <0>; >>>>>>>> >>>>>>>> stn-565-mode = <0>; >>>>>>>> >>>>>>>> mono-8bit-mode = <0>; >>>>>>>> >>>>>>>> sync-edge = <0>; >>>>>>>> >>>>>>>> sync-ctrl = <1>; >>>>>>>> >>>>>>>> raster-order = <0>; >>>>>>>> >>>>>>>> fifo-th = <0>; >>>>>>>> >>>>>>>> }; >>>>>>>> >>>>>>>> display-timings { >>>>>>>> >>>>>>>> native-mode = <&timing0>; >>>>>>>> >>>>>>>> timing0: 1280x800 { >>>>>>>> >>>>>>>> clock-frequency = >>>>>>>> <70000000>; >>>>>>>> >>>>>>>> hactive = <1280>; >>>>>>>> >>>>>>>> vactive = <800>; >>>>>>>> >>>>>>>> hfront-porch = <80>; >>>>>>>> >>>>>>>> hback-porch = <60>; >>>>>>>> >>>>>>>> hsync-len = <20>; >>>>>>>> >>>>>>>> vback-porch = <12>; >>>>>>>> >>>>>>>> vfront-porch = <8>; >>>>>>>> >>>>>>>> vsync-len = <3>; >>>>>>>> >>>>>>>> hsync-active = <0>; >>>>>>>> >>>>>>>> vsync-active = <0>; >>>>>>>> >>>>>>>> }; >>>>>>>> >>>>>>>> }; >>>>>>>> >>>>>>>> }; >>>>>>>> >>>>>>>> >>>>>>>> But when i play a video or when i have many frames on the display i >>>>>>>> get some screen flickers. >>>>>>>> >>>>>>>> >>>>>>>> On the log via UART i see the following: >>>>>>>> >>>>>>>> >>>>>>>> 1- When booting up: of_graph_get_next_endpoint(): no port node >>>>>>>> found in /ocp/lcdc@4830e000 >>>>>>>> >>>>>>>> 2- When video or many frames are displayed: >>>>>>>> >>>>>>>> tilcdc 4830e000.lcdc: tilcdc_crtc_irq(0x00000020): FIFO >>>>>>>> underflow >>>>>>>> >>>>>>>> tilcdc 4830e000.lcdc: tilcdc_crtc_irq(0x00000004): Sync lost >>>>>>>> >>>>>>>> >>>>>>>> Any idea? >>>>>>>> >>>>>>>> >>>>>>>> Is the DDR flash rate to slow? Or the DMA buffer not big enougth? >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>> For more options, visit http://beagleboard.org/discuss >>>>>>> --- >>>>>>> You received this message because you are subscribed to the Google >>>>>>> Groups "BeagleBoard" group. >>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>> send an email to [email protected]. >>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>> >>>>>> >>>>>> -- >>>>> For more options, visit http://beagleboard.org/discuss >>>>> --- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "BeagleBoard" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to [email protected]. >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> >>>> >>> -- >> For more options, visit http://beagleboard.org/discuss >> --- >> You received this message because you are subscribed to the Google Groups >> "BeagleBoard" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> For more options, visit https://groups.google.com/d/optout. >> > > -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
