yashsingh1/xdaforums huggingface dataset:
[General Omni Discussion] cgx:
I'm running cppcheck on the kernel sources atm.

Found many buffer overflows like this in the samsung lcd drivers (at least ld9040.c, s3cfb_ea8061.c, s3cfb_s6e39a0.c, s3cfb_s6e8aa0, s3cfb_s6e8ab0, s3cfb_s6evr01.c, s3cfb_s6evr02.c, s6dr171.c, s6e8aa1.c)

static ssize_t lcd_type_show(struct device *dev,
struct device_attribute *attr, char *buf)
{
char temp[15];
sprintf(temp, "SMD_AMS480GZ01-0\n");
strcat(buf, temp);
return strlen(buf);
}

Wondering if these lcd_type functions are normally called and could cause problems (stack corruption, stack pushed registers overwritten?).

also don't know if media/video/exynos/tv/mixer_reg.c is in active use, but in function mxr_reg_local_path_set

int mxr0_local = mdev->sub_mxr[MXR_SUB_MIXER0].local;

int mxr1_local = mdev->sub_mxr[MXR_SUB_MIXER1].local;

the code is accessing beyond the array which is defined size 1 for exynos4

There are still a lot of other files to look at...

Thanks for your debugging efforts. There may be another operation (opendir/readdir?) that has similar issues with variables getting corrupted. I'll look at this if it looks like the underlying bug may not get fixed soon. I'm now putting my little extra time on finding the bug.
[General Omni Discussion] clumsy:
thanks!!

If I can test or provide any more information, just let me know! It's really strange as it only happens when the device is off and abviously trying to go to deep sleep, which gets prevented by the sdcard/mediascanner by a wakelock....
[General Omni Discussion] FrodgE:
Awesome work cgx, this issue has buffer overrun written all over it - finding them is a challenge ! Curious though, were these problems you're finding introduced with KK or have they been there since the dawning of time and only now are they coming to the surface ?
[General Omni Discussion] dahias:
:mad:

He's right - I have the same issue with the scheduled titanium backup jobs!

So file copies work as described in my previous post, but something's still wrong somehow...

The good thing is: It seems this problem does not really affect the battery drain, the job just hangs and can't be canceled :eek:
[General Omni Discussion] Twiq:
Just a quick tip guys.. titanium backup is using it's own busybox and sqlite, and i often get lockups when backing up stuffs when it uses its own binaries especially on kitkat rom builds (not sure it happened on JB or lower tho, must be permission issue on kitkat).

However there's a workaround, if you guys use Pro version of TiBu then you could fire it up, go to preferences and open troubleshooting (most bottom) then select force system busybox and sqlite.. That should resolve stucking up on backup/restoring in TiBu. ?

Running 0401 Sabered SlimKat | DorimanX 10.43v99.1
[General Omni Discussion] lerkin:
Thank you, really great suggestion, gonna try that out.

I have two other devices on 4.4 (n4 and nook hd plus) - they do not have any problems with scheduled tb jobs though. But they have emulated storage and no permission problems because of that?

Edit: and dropsync hung in the beginning of syncing process. I am giving up.
[General Omni Discussion] Dr.69:
Just a little reminder. Dropsync and Titanium Backup work perfectly after formatting both of the SD cards to exFAT.

And thanks to all of you who are trying to find a solution :)
[General Omni Discussion] Toruk.Makto:
Any Success/hope in that ???
[General Omni Discussion] FrodgE:
Wow, you weren't joking ! This issue has sparked my curiosity and interest in learning a little more about Android & Linux. I've now setup a working build environment and based upon your lead have also run cppcheck over the kernel source.

Let me know if you'd like a hand fixing these issues (starting with the overflows). I don't want to tread on your toes or steal your glory etc. I just need to come up to speed on git (already learnt the hard way some things you shouldn't do !). We will be transitioning to git at work shortly so this will also be a good intro for me. Work/life is pretty busy so no guarantee I'll have a lot of time...

[MENTION=591147]Entropy512[/MENTION] is there anything I should know or read over before getting involved and contributing ? (and that includes you telling me to get my stinking filthy hands off your source code and leave it to the experts ;) )
[General Omni Discussion] Entropy512:
Well, in that particular case, while it has a potential for being a buffer overflow if the input string is "bad" - in this case the input string is a fixed string so there is no risk of a buffer overflow.

lcd_type_show() would only be called when something reads the lcd_type sysfs file.

I'll try to remember to put up kernels compiled with GCC 4.6 to see if they improve things later. Also, it looks like dorimanx pulled in a modem driver from i9300 update12, while we're still using an older one... might be relevant.
[General Omni Discussion] cgx:
This is not just risk of overflow, it IS actually overflow. temp buffer is 15 bytes and the input string is longer than that (in all the files I listed above)
[General Omni Discussion] Entropy512:
That teaches me to read through code without enough caffeine/sleep. The strings didn't look like they were more than 15 bytes.

wtf samsung?

Attached are kernels built with GCC 4.6 instead of 4.7 - no other changes.

Well the SHOULD be built with 4.6 if I actually set things up right.
[General Omni Discussion] cgx:
Right, why even bother with the sprintf? Directly strcating the string should be fine.

Unfortunately, I see no improvement with this kernel :(

omni stock apr17:

# uname -a

Linux localhost 3.0.64-OMNI-g9de8607 #1 SMP PREEMPT Thu Apr 17 17:57:25 CEST 2014 armv7l GNU/Linux

Run 1: copy stuck at 45219840

Run 2: copy stuck at 147062784

Run 3: copy stuck at 49414144

gcc 4.6 kernel for i9100:

# uname -a

Linux localhost 3.0.64-OMNI-gb48967e #1 SMP PREEMPT Wed Apr 16 20:06:13 EDT 2014 armv7l GNU/Linux

Run 1: copy stuck at 94502912

Run 2: copy stuck at 186908672

Run 3: copy stuck at 94896128
[General Omni Discussion] m4dm4xi:
Me unfortunately neither. I´ve been testing the night...

Still random hang ups with different apps.

Thanks for your efforts nevertheless!

If I understand it correctly a change of compiler couldn´t actually help if the culprit really is the overflow, right?

Seems like cgx patch was a step in the right direction but not fully developed yet :)

Please keep up the work! It´s much appreciated.
[General Omni Discussion] Entropy512:
Really depends on if the overflow is one of Samsung's bugs in the kernel (which would be strange since their own devices seem to work OK)

My next thing to look at (likely not until next week) is to pull in new modem drivers, since people claim this issue disappears on dorimanx' kernel.
[General Omni Discussion] Red_Vex:
So file operation with dori go fine?
[General Omni Discussion] lerkin:
For me fuse hangs with dorimanx's (latest).
[General Omni Discussion] FrodgE:
What's the likelihood Samsung build & deploy DEBUG builds rather than release builds ? I'm not up to speed (yet) on the options that get passed to the compiler etc but I'm thinking along the lines of variable initialisation & array padding, and perhaps to a lesser extent optimisations. (speaking from MS experience rather than Linux, I assume the same applies)

From what I've read I was of the impression that NONE of the various ROM's or kernels available have "fixed" this issue. Personally I've tried Dorimanx & Gustavo and both still exhibit this behaviour.
[General Omni Discussion] m4dm4xi:
You misunderstood something somewhere. Dorimanx does not work either!
[General Omni Discussion] Entropy512:
OK, people were claiming it was OK...

grumble grumble... this is proving to be such a #$@*)#@*$)@ pain in the ass
[General Omni Discussion] Red_Vex:
Just to know... If hangs of fuse daemon is caused by buffer overflow Why problem didnt occour with exFat? Buffer overflow is indipendent from fs in this case right?
[General Omni Discussion] j1gga84:
I am on latest [MENTION=2376110]dorimanx[/MENTION] beta (v107) and I have absolutely no issues with fuse daemon.

Dorimanx kernel had issues in the past but since last releases they seem to be gone but I can only talk for me.

I can transfer 1gb of music between internal and external SD without a problem. Also thumbnails load as they should (a bit slowly but they load). BTW I have also no problems with [MENTION=4217277]Gustavo_s[/MENTION] kernel.

Regards

Sent from my GT-I9100 using german Tapatalk 4
[General Omni Discussion] lerkin:
Tested 107, no luck, dead end.
[General Omni Discussion] Red_Vex:
Your ext sd is exFat?
[General Omni Discussion] j1gga84:
external and internal SD is standard formatted and exFat support for Dorimanx was implemented with v108 from today, so no wonder if you have no luck with v107 ;)

Regards
[General Omni Discussion] kulwinderjj:
Never heard about this file format. "standard format"
[General Omni Discussion] j1gga84:
it must be vfat I think

regards
[General Omni Discussion] Entropy512:
I don't think it's a buffer overflow.

If it were, then cgx's tricks for forcing those variables to be in memory instead of registers would have made things worse, not better.

Seems like some sort of issue with restoring state after an interrupt, but it's still really just a guess. It's likely timing related and using exfat as an underlying filesystem changes the timing (or alters the behavior of pread64() in other ways).

All we know is:

A function sets up a few variables

Then that function calls the pread64() syscall (which reads data from the underlying filesystem - so changing to exfat is going to fundamentally change how this call does its thing)

When pread64() returns, some of the variables in the function that called it have been corrupted - even though in any sane system there is no way for that to happen. (In a properly working system/compiler, if you never pass a variable to a function it should NEVER be touched. Even if you pass a variable to a function, if you didn't pass it via a pointer, it shouldn't be touched.)

That's what makes this so difficult to debug - we know why the problem is happening, we know exactly which function is causing the problem, except *there should not be any way that function can cause this kind of problem* (and we can't replace the function with something else... reading data from the underlying filesystem is pretty damn important.)
[General Omni Discussion] Red_Vex:
So i suppose that replace that function with an old jb one that works correctly is impossible right?
[General Omni Discussion] Entropy512:
It's a kernel function that hasn't changed in years. Why it causes corruption in the fuse sdcard daemon but not other stuff is not yet known... I'm honestly surprised this isn't screwing up other stuff too.
[General Omni Discussion] bleggy:
does cgx's script need to be flashed after flashing an update or custom kernel? dumb question, sorry.
[General Omni Discussion] Twiq:
Not necessary if the update doesn't replace /system/bin/sdcard. Most custom kernel doesn't touch /system/bin. But rom upgrade replaces them.

If the developer hasn't implement cgx's patches to the rom then you may reflash the script, but if they already implement it then there's no need to flash it again

Running 0416 Sabered SlimKat | DorimanX 10.43v108
[General Omni Discussion] Red_Vex:
I try cm11 with and without workaround of cgx and try to restore from tb.

Hangs in both case even if with cgx workaround take a bit more.
[General Omni Discussion] lerkin:
yep (
[General Omni Discussion] NaminatoR1254jaime.sier:
Did you update Superuser Binaries before trying to restore with TB?

I had the same issue months ago and I it always hanged.

I learnt that

1- You need to have the binaries updated

- Download Superuser app from Playstore and update binary.

2- Keep the screen on.

- Everytime I "locked" the phone, it'd hang.

Now I restore my backups while charging (yeah, bad thing, I know) and leave the screen on.
[General Omni Discussion] Red_Vex:
Yep i installed a flashable superuser from chainfire site and update su binary.

honestly i have not see if the display go off b4 hangs....Btw those are a workaround.....and i often make sd card operation.....so Every KK rom till have this bug is out for me :(
[General Omni Discussion] Twiq:
http://xdaforums.com/showthread.php?p=51820234

Quoting myself

Running 0416 Sabered SlimKat | DorimanX 10.43v108
[General Omni Discussion] NaminatoR1254jaime.sier:
Check the screen thing. Now I do it with the screen on and I dont even touch the phone and it works.
[General Omni Discussion] CRXed:
How do I enable Expanded Desktop mode?

When checking that option to enable it, nothing happens.

EDIT: oops, sorry wrong thread
[General Omni Discussion] razkal1:
Think your in the wrong thread mate

Sent from whereever iam...
[General Omni Discussion] FrodgE:
sigh, I'm keen to try and help debug this problem but would you believe my phone now insists on working without fault ? The nerve ! The problem used to happen regularly enough to motivate me to format everything to exFat rather than Fat32. I've since reverted back to Fat32 on both internal & external, removed the workaround provided by cgx, and it's rock solid. Normally I'd be happy, now I'm annoyed. Copying files between internal and external is fine, playing music is fine, I can't break it damn it ! Does anyone have tips on how to make it fall over ?

There are some differences b/w my setup today and that of a few weeks ago but I wouldn't have thought they're significant:

- homebrew omni compile (no changes yet)

- strace running in the background attached to the sdcard processes logging to /data/log/

- old class 4 8GB micro sd upgraded to 32GB class 10 micro sd
[General Omni Discussion] Entropy512:
IIRC, it was REALLY tough for cgx to catch this bug in the act with strace active - again, it seems timing sensitive. When Chainfire turned on the sdcard daemon's debug logging, it masked the problem.

So try dropping strace and maybe adding the debugging changes cgx made a few posts prior to his workaround post. (Printing the values of some of the variables before/after pread64() is called)

I'm not sure if running strace on the daemon matters any more, considering we know exactly where it's failing. We just haven't yet figured out why pread64() seems to occasionally be corrupting data.
[General Omni Discussion] FrodgE:
Thanks for the tip. I do recall you saying that enabling the daemon debug logging altered the timing enough to prevent the issue occurring so I didn't enable that but I wasn't sure if strace would have the same impact. I was actually only using strace to capture the stderr output stream. I'll see if I can redirect to a file in /data/log instead.

I am using some debug statements similar to the changes cgx made but using ERROR rather than TRACE (because I didn't enable it), so it wasn't entirely true that I haven't made changes - just nothing significant. Unlike the change cgx made I'm not trying to mask the fault, just detect if it happens and only then print a debug statement so for the most part execution should remain unchanged.

Ultimately I plan to go digging around in the kernel rather than the daemon but until I can create a test environment there's little point.
[General Omni Discussion] philippe734:
Music bug + Video recording lag = same issue

Running CM11 snapshots build since several months on i9100, with up to date by OTA. I confirm that the music bug is already here and very random and rare. I think there is a link between this music bug and the camera lag. I mean, there is also a random camera lag when recording. During video recording with the camera (1080p or 720p), sometimes there are small barely perceptible jerks (lags), rare and difficult to see. Which are best seen on big screen while playing. I’m sure that the music bug is the same that the lags while recording video. I think this issue is from the speed of write/read on memory, not enough fast, kind of this type.
[General Omni Discussion] XxPixX:
I'm not sure if this helps, but I have never had it freeze when listening to music through mycloudplayer. It's basically a soundcloud music player however even though ALL of my tracks are cached locally on my internal memory, I have yet to meet a freeze.
[General Omni Discussion] spirohan:
My first freeze on AOSB was with Mycloudplayer but i don't know if my cached tracks were on the internal or external memory :confused:
[General Omni Discussion] lerkin:
http://review.cyanogenmod.org/63946

That commit from latest cm nightly, isn't it a fix?

Nope, it's not (
[General Omni Discussion] Red_Vex:
Doesn't change anything?
[General Omni Discussion] lerkin:
Yep, still hangs on copy process.
[General Omni Discussion] Entropy512:
That's a fix for a security vulnerability that was recently disclosed
[General Omni Discussion] Red_Vex:
When i Read your Nickname and the word "fix" i was just near to die
[General Omni Discussion] cooldued17:
Dorimanx possible fix?

Having recently come to the knowledge of this rather annoying bug, I scoured the internet for information with hope to find a fix.

A few hours later I found something and wonder if someone with more intimate knowledge would know if this will help to bury our issue here:

A "nofuse" kernel mode I/O driver for exFat and Vfat(fat12/16/32).

(Dang it XDA, I can't post links! Please add the .com to github :p) github /dorimanx/exfat-nofuse
[General Omni Discussion] Tann San:
I had constant problems as described in this thread when I was using Fat32 so I formatted the external so that doesn't seem to be causing problems anymore but I left my internal as it was. Several times a day it starts to get really hot and if I leave it the battery will drain very quickly and in a few rare cases it's restarted. The problem seems to happen when assets on the internal memory are accessed like custom ring-tones, message sounds etc. My hunch is that the system is trying to access these files and it's running into the same issue as described in this thread. It's kinda annoying as it means I have to keep an eye on my battery level all day and if the phone gets hot then it's time for a shutdown.

I thought I'd share my current experience to see if anybody else is seeing the same kind of thing. I know there are people working on this but it still drives me c-r-a-z-y that this is ongoing, hope you get a break with a solution soon :good:

As a backup plan, is this problem because of trying to run KitKat on the N7000 or will it still be present if I was running with a new note model, still with KitKat?
[General Omni Discussion] Entropy512:
Nope. That isn't of use for Google's new kitkat fuse sdcard daemon stuff.

It only occurs on Exynos 4210 devices (I9100, I777, N7000 are the only devices in this category supported by Omni). I'm kind of surprised we haven't been seeing similar behavior on Exynos 4412 devices (same kernel, nearly same processor) unless there's some sort of ARM cache errata or something that Samsung fixed between 4210 and 4412.
[General Omni Discussion] bleggy:
I have my external sd card formatted exfat and I flashed the zip posted in this thread to fix up the internal. no problems at all since. flash that zip and you'll be cool.
[General Omni Discussion] NaminatoR1254jaime.sier:
I took a look at the omnirom changelog and there's a commit about sd card on the 1st Feb. Maybe that did it. Anyway it'd be Cool if other roms took carne of that too.
[General Omni Discussion] D4rK.F0rcE:
When you guys talk about sd card, do they mean ex.sdcard only or both, internal and ex.sdcard?

From what I observed, it doesn't matter if you play music form internal or external sdcard, in both cases music stops after some time. Even if you take out the ex. sd card and play music form internal storage, the music will stop.

Using different music apps does not solve the problem either (music also stops using the apollo music player). However, using tunein radio player, everything works fine, so far (I am not sure if this is coincidence).

I tried to play music while on airplane mode. And my impression was that the music was playing for al longer time... however, eventually it stopped.

Those are my observations, maybe they will help to find the culprit ;)
[General Omni Discussion] bleggy:
I usually keep about 25 gigs of music on an external sd card. I do not recall ever having a freeze-up/reboot while listening to downloaded mp3 podcasts on the internal card, but I mostly listen to media from the external.

I listen to music about 2-4 hours a day at work and commuting on the subway. I have not had any freezes/reboots this week, so perhaps things are resolved. If it happens though, I'll post.
[General Omni Discussion] Entropy512:
It's more that this is a really nasty bug that is a ***** to track down. It seems to come and go and affect some people more than others. Sometimes it won't affect someone for a few days making them think it's fixed when it isn't. When Chainfire attempted to crank up the FUSE daemon's debugging, the problem went away. (I hate heisenbugs!)

For example Chainfire's "screen on" hack for OpenDelta worked around the issue for many but not all.

The problem is we don't know why the fuse daemon derps up on these devices and only these devices - Only the Exynos 4210 devices are affected. One of my theories was that it might be an outdated FUSE driver. I attempted to update it, but so far it sounds like it might have caused more problems than it solved (although there could have been user error... https://gerrit.omnirom.org/#/c/5307/

I'm going to try doing test kernels for i777 and n7000 tonight or tomorrow with that patch.
[General Omni Discussion] bleggy:
well, my music stopped today. I spoke too soon. on 2-06 nightly.

The bug definitely is random. [MENTION=2185662]Entrophy[/MENTION]512 - should we all try to get a log? Let us know.
[General Omni Discussion] DJG0A:
Yes, how can we help with this issue ?
[General Omni Discussion] Entropy512:
Unfortunately, the fuse daemon normally doesn't log very much.

There's a SLIGHT possibility there might be something in dmesg when it happens, but I'm not sure.

If you try to crank up logging in the fuse daemon to see where it's hanging - the bug goes away. The logging alters the timing enough to mask the bug. As I said - I hate heisenbugs. :(