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] > <javascript:>> 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] <javascript:>> 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] <javascript:>. >>> 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.
