maemo.org - Talk - [N900] Yes, another hildon-home bug thread...

maemo.org - Talk (https://talk.maemo.org/index.php)

- Maemo 5 / Fremantle (https://talk.maemo.org/forumdisplay.php?f=40)

- - [N900] Yes, another hildon-home bug thread... (https://talk.maemo.org/showthread.php?t=86804)

Re: [N900] Yes, another hildon-home bug thread...

I must say since I purged all external-loaders incl widgets I haven't had a lockup... Yet due various reasons my uptime hasn't be longer than 3 days, though

But still I had a lockup(the one I mentioned earlier) once and I didn't have dcew installed so qbw may be compromised too?

Re: [N900] Yes, another hildon-home bug thread...

I do not find dbg symbols for dcew?

And yeah it seems also other widgets are compromised (or it is h-h itself?).

But what? It is a file read, yes. But which one?
It could be config, which is there and accessible.
Or it could be something from /proc or /var (reading uptime, temp, batt, boot reason and IPs). Or maybe thread problem while synchronous access to one of these (overall Maemo prob?)?
???

--edit

Quote:

(gdb) info threads
* 1 Thread 0x4001eeb0 (LWP 20403) 0x401886f4 in read () from /lib/libc.so.6

Re: [N900] Yes, another hildon-home bug thread...

Quote:

Originally Posted by peterleinchen (Post 1301080)

I do not find dbg symbols for dcew?

That's bad, blame the developer for not providing -dbg package.

Quote:

And yeah it seems also other widgets are compromised (or it is h-h itself?).

It seems the only compromised widget on your device is dcew, both backtrace and info threads clearly show that.

Quote:

But what? It is a file read, yes. But which one?
It could be config, which is there and accessible.
Or it could be something from /proc or /var (reading uptime, temp, batt, boot reason and IPs).

I/O operations does not block on simple files, so it has blocked on pipe/socket/fifo/who_knows_what_else. I'd recommend to check your dcew configuration and figure out what falls in the above list.

Quote:

Or maybe thread problem while synchronous access to one of these (overall Maemo prob?)?
???
--edit

Yeah, or little green man :p . Your info threads command clearly shows there is only one active thread, which is doing blocking I/O in dcew. So it is either bug in dcew or dcew is broken by design. Or dcew does not support your custom configuration.

EDIT:

you can explore a bit /proc/$PID_OF_H_H/ to see if you can find which files are accessed by h-h. For sure you can find the file descriptors of open files, but right now I cannot tell you how to find the file from its file descriptor in shell.

Re: [N900] Yes, another hildon-home bug thread...

@peterleinchen: I looked at dcew code, this is broken by design:

Code:

        if(self->priv->flagBooted || self->priv->updOnBoot)

        {

                fp = popen (self->priv->instanceCmd, "r");

                

                /* AP; No!No!No!Yes!, thanks! */

                //        while (fgets (line, sizeof line, fp)) {//Needed to change this "line-based" management for output //AP

                if (l=fread (line, 1, sizeof line, fp)) {//to this "buffer-based" for multiline handling in widget //AP

                        line[l-1]='\000';//AP

                        

                        gtk_label_set_text (GTK_LABEL (self->priv->cmdResult_lb), line);//AP

                        found = TRUE;

                }

                pclose (fp);



                if (!found) {

                        gtk_label_set_text (GTK_LABEL (self->priv->cmdResult_lb), "Invalid Command");

                }

Now, if the process started with popen does not flush its STDOUT and does not exit, dcew will block till eternity in fread (...) call. And this is what happens on your device. Period. Pester the developer of dcew to implement it in the correct way - by either using threads, or setting the file descriptor in non-blocking mode or using select() or ... .

Re: [N900] Yes, another hildon-home bug thread...

Quote:

Originally Posted by freemangordon (Post 1301217)

Code:

if (l=fread (line, 1, sizeof line, fp)) {//to this "buffer-based" for multiline handling in widget //AP

Thanks for that freemangordon!

Question to peterleinchen: what DCEW's are you using? on one of my N900s I use it (uptime, ip, custom-script-for-battery-voltage-via-i2cget), but I normally don't keep that one turned on for more than a few minutes, so I haven't experienced any problems.

In any case, if the popen'ed process exit()s then stdout is flushed and the problem should NOT occur. Meaning you are executing a command that is itself blocking (for input?) or stuck in an infinite loop.

Can anyone comment on QBW? is that any better than DCEW?

Re: [N900] Yes, another hildon-home bug thread...

Quote:

Originally Posted by reinob (Post 1301226)

Can anyone comment on QBW? is that any better than DCEW?

I'd say so but I have the h-h issues having never used DCEW.
I do however have QBW.
I have a friend still on PR1.3.1 with the issue but not as bad; that has never used DCEW or QBW.
The only thing I can see that could be effecting his device is Data monitor widget and/or Oculo.

Is it likely we are searching for multiple different bugs in different applications with the same symptom?
As I have mentioned before I have ran my device with no widgets at all and still had the issue.

Re: [N900] Yes, another hildon-home bug thread...

It seems my QBW replacement version of DCEW's Battery % hung today. At least there's no way updating the shown value anymore, not on click / not on desktop change. This was after several days of uptime.
Now i would not say at all that h-h's widget core is matured...

EDIT: even fully charging the battery (OOTB method) didn't reset the displayed value. It decided to stay at 52%.

Re: [N900] Yes, another hildon-home bug thread...

Quote:

Originally Posted by freemangordon (Post 1301209)

That's bad, blame the developer for not providing -dbg package.

Yeah, but when gone he is gone.

Quote:

Originally Posted by freemangordon (Post 1301209)

It seems the only compromised widget on your device is dcew, both backtrace and info threads clearly show that.

Yes, sure. I was talking about mr_pingu's comment (QBW also compromised). But maybe we all suffer from same/similar coding bug.
Or what?

Quote:

Originally Posted by freemangordon (Post 1301209)

I/O operations does not block on simple files, so it has blocked on pipe/socket/fifo/who_knows_what_else. I'd recommend to check your dcew configuration and figure out what falls in the above list.

EDIT:
you can explore a bit /proc/$PID_OF_H_H/ to see if you can find which files are accessed by h-h. For sure you can find the file descriptors of open files, but right now I cannot tell you how to find the file from its file descriptor in shell.

I tried but did not yet understand how to interprete such output from /proc/xxxx/fd:
0 -> pipe:[3666]
Will continue ...

Quote:

Originally Posted by freemangordon (Post 1301209)

Yeah, or little green man :p

I think so :D

Quote:

Originally Posted by freemangordon (Post 1301209)

Your info threads command clearly shows there is only one active thread, which is doing blocking I/O in dcew. So it is either bug in dcew or dcew is broken by design. Or dcew does not support your custom configuration.

Quote:

Originally Posted by freemangordon (Post 1301217)

@peterleinchen: I looked at dcew code, this is broken by design:

Code:

                fp = popen (self->priv->instanceCmd, "r");

                

                if (l=fread (line, 1, sizeof line, fp)) {//to this "buffer-based"                 }

                pclose (fp);

Now, if the process started with popen does not flush its STDOUT and does not exit, dcew will block till eternity in fread (...) call. And this is what happens on your device. Period.

Thank you again very much for looking into other people's problem.
I would not have seen that even I had looked into.

But I still do not understand really how that may happen:
Here are all commands that are executed with DCEW:

Quote:

c_commands=
uptime|cut -d" " -f4-|sed 's/\\, *load.*//';
hal-device bme | awk '/l.p/ {perc = $3}\;\s/s_c/ {isch = $3} END if (isch == "false") {print perc" %"} else {print "Chrg"}';
hal-device bme | grep battery.reporting | awk -F. '{print $3}' | sort | awk '$1 == "current" { current = $3}\;\s$1== "design" {print current "/" $3}';
cat /proc/bootreason;
cat /var/lib/dsme/boot_count;
wget -q -O - api.myiptest.com | awk -F "\"" '{print $4}';
/sbin/ifconfig | grep "inet addr" | awk -F: '{print $2}' | awk '{print $1}';
df | awk '$1 == "rootfs" {print $5}';
df -h | awk ' $1 == "rootfs" {print $4"B"}';
hal-device bme | grep "battery." | sort | awk '/l.p/ {perc = $3}\;\s/g.c/ {curr = $3}\;\s/g.la/ {last = $3}\;\s/g.des/ {design = $3}\;\s/s_c/ {isch = $3} END if (isch == "true") {printf "!Ch! "}\;\sEND {print perc"% ("curr"/"last"/"design" mAh)"}';
printf "Rsn: " && printf `cat /proc/bootreason` && printf ", Cnt: " && printf `cat /var/lib/dsme/boot_count`;
echo $(sudo i2cget -y 2 0x55 0x06 w\;\scat /sys/devices/platform/omap34xx_temp/temp1_input) | awk '{ print $1*0.25-273 " \$"$2"\$ °C"}';
wget -t 2 -T 3 -q -O - api.myiptest.com | awk -F "\\"" '{print $4" \\n("$12" @ "$20", "toupper($28)")"}';
sudo iwconfig wlan0 txpower 20\;\srun-standalone.sh /usr/bin/dbus-send --type=method_call --dest=org.freedesktop.Notifications /org/freedesktop/Notifications org.freedesktop.Notifications.SystemNoteInfoprint string:"WLAN power set to 100 mW";
wget -t 2 -T 3 -q -O - checkip.dyndns.com | awk -F ": " '{print $2}' | awk -F "</" '{print $1}';

Most of them only excuted on click and switching desktop. Only boot reason and uptime on boot; and network (IP) also on network connected. I do not see any of them to cause the block! Or?

Re: [N900] Yes, another hildon-home bug thread...

Quote:

Originally Posted by don_falcone (Post 1301273)

It seems my QBW replacement version of DCEW's Battery % hung today. At least there's no way updating the shown value anymore, not on click / not on desktop change.

don
could you click any other widget on desktop (not counting are contacts or browser links)? Or was it also totally "frozen"?

Re: [N900] Yes, another hildon-home bug thread...

Everything else mentioned worked, IIRC. Only updating the value wasn't.