Release PNDManager

[porg]

@B-ZaR: Bug Prevention Idea:

PNDManager looks for a flag file like "version-x-x-x-already-ran-once" at start up, and if not found runs an init script like rm -r /media/*/pandora/appdata/libpndman/ to ensure that previous (potentially malicious caches) are removed. Because we are seeing this kind of user report almost after every 2nd revision or so, which can simply be solved by clearing its appdata. Is their any downside to this? I think their is no danger of data loss (except if their were preferences like "don't update app X"), cause everything is contained in the PNDs anywhere and the appdata is mostly a cache folder, ain't it? Or you structure the appdata file in a way, with files&folders which should stay (prefs), and things which can be purged (caches) for possibly resolving issues.

 

[bzar]

Porg, I'm VERY wary of running such commands on peoples' pandoras. Any number of things can go wrong and end up deleting a lot of stuff it shouldn't. Something like that (like tell libpndman to overwrite existing databases) maybe, but not like that

I'd much rather this wasn't needed in the first place, though. Anything like that is more hiding the issue than fixing it.

 

[Rockthesmurf]

I've mentioned this before in another thread, but I would have thought all PNDs should have code like this in them:


static const bool kUseExceptionHandler = true;

void handler(int sig)
{
void *array[ 16 ];
size_t size;

// get void*'s for all entries on the stack
size = backtrace(array, PiArraySize( array ) );

// print out all the frames to stderr
fprintf(stderr, "Error: signal %d:\n", sig);
backtrace_symbols_fd( array, size, 2 );
exit( 1 );
}

int main( int argc, char ** argv )
{
if ( kUseExceptionHandler )
{
signal(SIGSEGV, handler);
signal(SIGBUS, handler);
}

// Etc.
}

With code along the lines of the above in place, when a crash occurs, it'll dump out the callstack (which presumably will show up in the PND log file), then when a user posts their log you will see what the callstack is. The callstack will appear as hex addresses, so be sure to keep an (unstripped) version of the executable around, as then you can use addr2line to get more useful information (filename, line number and function name).

 

[fusion_power]

OK, I had to delete the appdata folder to get PND Manager working again correctly, even after the update (crashed to desktop when selecting certain PNDs for detailed view). Now it seems to work again like it should but I wonder if the update process still causes this strange behaviour. Maybe I just update PND Mannager external and not by itself, seems saver.

 

[bzar]

Fusion_Power: Next time you update pndmanager make sure the PND is properly unmounted before before starting it again. The behavior you're seeing may be because of an unsuccessful unmount for some reason.

 

[apersonthinks]

Segfaults when I try to update package list.

 

[Hồng Thất Công]

Segfaults when I try to update package list.

delete both the "libpndman" and "pndmanager" folders in the appdata folder , restart your pandora, and it should work

 

[fusion_power]

Fusion_Power: Next time you update pndmanager make sure the PND is properly unmounted before before starting it again. The behavior you're seeing may be because of an unsuccessful unmount for some reason.

I don't remember to mount/unmount anything on my Pandora at all. ^^"  I just open/close the programs like normal.  Is there an indication if a program is correctly unmounted?

 

[Loonie]

I'm having the CTD problem when refreshing the database as well. Deleting the aforementioned directories and rebooting didn't help. PND output was quite unusual, and Mousepad didn't know what format it should be. Behold the interesting part:

@FILE pndman.c             @LINE┬á67   >> _pndman_get_tmp_file
Created temporary file.
@FILE curl.c               @LINE┬á220  >> _pndman_curl_handle_perform
url: http://repo.openpandora.org/client/masterlist?bzip=true
@FILE curl.c               @LINE┬á310  >> _pndman_curl_msg
HTTP/1.1 200 OK
Date: Fri, 04 Oct 2013 03:11:45 GMT
Server: Apache
X-Powered-By: PHP/5.4.4-14+deb7u4
Cache-Control: public
Etag: 1380834366
Last-Modified: Thu, 03 Oct 2013 21:06:06 GMT
Content-Length: 299198
Connection: close
Content-Type: application/x-bzip2


@FILE curl.c               @LINE┬á316  >> _pndman_curl_msg
BZh41AY&SYÉ┘)

@FILE pndman.c             @LINE┬á67   >> _pndman_get_tmp_file
Created temporary file.
QPndman::Repository::update
QPndman::Repository::update
Crawling
Segmentation fault
[ FAILED]--- Starting the application ( scripts/panorama.sh  ) ----------
[ START ]--- Restoring the frame buffer status ----------
[sUCCESS]--- Restoring the frame buffer status ----------
[ START ]--- uMount the PND ----------
[ START ]--- Waiting the Union to be available ----------
[sUCCESS]--- Waiting the Union to be available ----------
auplinklink.c:223: AUFS_CTL_PLINK_MAINT: Inappropriate ioctl for device
rmdir: failed to remove `/mnt/utmp/pndmanager': Device or resource busy
[ START ]--- Waiting the PND mount dir to be free ----------
[sUCCESS]--- Waiting the PND mount dir to be free ----------
cleanup done
[sUCCESS]--- uMount the PND ----------
=======================================================================================
Return code is : 2
 

 

[Hồng Thất Công]

^hmm weird.  I got segfaulted too but after deleting those  directories and restarted everything works like a charm.

 

[bzar]

Fusion_Power: The PND system mounts and unmounts the PNDs as you run and quit them. You can see if the PNDManager PND is still mounted by checking if pndmanager's directories in (IIRC) /mnt/pnd/ and /mnt/utmp exist and are not empty.

Loonie: Do you have PNDs from outside the repo? Which ones? Cloudef has tested libpndman to work with all the PNDs in the repo and then some, but apparently you have some PND that's causing issues.

 

[Neelix]

PND mount folders can sometimes continue to exist after a PND has been unmounted, so that's not the best way to check.

If you open a terminal and type:
 


mount |grep pndmanager

and the result looks something like this:
 


/dev/loop2 on /mnt/utmp/pndmanager type squashfs (ro,relatime)
none on /mnt/utmp/pndmanager type aufs (rw,relatime,si=21f5655b,noplink)

That means it's still mounted. (if it's not mounted there probably won't be any output at all)


- Neelix

EDIT: I somehow missed the "and are not empty" bit of B-Zar's post. :rolleyes:

 

[bzar]

I've mentioned this before in another thread, but I would have thought all PNDs should have code like this in them:

...
With code along the lines of the above in place, when a crash occurs, it'll dump out the callstack (which presumably will show up in the PND log file), then when a user posts their log you will see what the callstack is. The callstack will appear as hex addresses, so be sure to keep an (unstripped) version of the executable around, as then you can use addr2line to get more useful information (filename, line number and function name).

There's a small problem with using something like this with panorama (which pndmanager is based on). Most running code is in dynamically loaded plugins, not the executable. This makes it (AFAIK) quite hard to find out the culprit with just a memory offset.

EDIT: I'm making a special debug build out of the current version. It will be slow as molasses but get your issue replicated there, post the pndrun output and I have something to work with

 

[Rockthesmurf]

@B-ZaR It feels like it should be telling you the module, this page http://stackoverflow.com/questions/6934659/how-to-make-backtrace-backtrace-symbols-print-the-function-names has a sample backtrace of:


BACKTRACE ------------
./a.out() [0x8048616]
./a.out() [0x8048623]
/lib/libc.so.6(__libc_start_main+0xf3) [0x4a937413]
./a.out() [0x8048421]
----------------------

I know I have certainly had multiple modules appearing in back traces that seem to all resolve okay (but they are also probably all modules that where known at compile time, which might make a difference).

 

[bzar]

Well, this works too

I've built a special PND that actually runs PNDManager inside a debugger (gdb) and prints out full stack trace and program state on exit. It can be quite a bit slower so don't use it unless you're having issues with the latest version.
 

http://bzar.fi/files/pndmanager-debug.pnd

 

[TrashyMG]

Interestingly enough your debug version doesn't crash on me.. It must be pressured to work properly with gdb watching it.

swapped back to the current repo version and it crashes again..

 

[Loonie]

Loonie: Do you have PNDs from outside the repo? Which ones? Cloudef has tested libpndman to work with all the PNDs in the repo and then some, but apparently you have some PND that's causing issues.

Good question. Wouldn't be the least bit surprised. I'll have to check.

 

[Cloudef]

Interestingly enough your debug version doesn't crash on me.. It must be pressured to work properly with gdb watching it.


swapped back to the current repo version and it crashes again..

The debug version also has latest libpndman from develop branch, which might be the reason it doesn't crash

I got some traces from friendly forum user as private message.

 

[bzar]

I'll make a non-debug version and post it here. If it works too I'll put it to repo.

 

[Loonie]

Okay, I had missed something. There was a libpndman subdirectory on both the SD cards, not just the one with PND Manager on it. I deleted that one, rebooted the Pandora, now all is well.