Release [Rebirth Comp] PandaFE

[gruso]

Starting this thread on behalf of nuhrin

Pandafe is a sort of "universal" SDL frontend for Pandora games and emulators.


Download: http://www.openpando...rth/pandafe.pnd

So, has anyone got this working? It starts for me, then crashes out after a few seconds. This is all I get on screen: http://i.imgur.com/k95uw.png


Output:

Spoiler

=======================================================================================


PND : /media/mmcblk0p1/pandora/desktop/pandafe.pnd


PND_FSTYPE : Squashfs


APPDATADIR : /media/mmcblk0p1/pandora/appdata/pandafe


APPDD_FSTYPE : vfat


PND_CPUSPEED : <unset>


EXENAME : bin/pandafe


ARGUMENTS : <unset>


=======================================================================================


[ START ]--- Mount the PND ----------


Mounting : mount -t squashfs -o ro "/dev/loop1" "/mnt/utmp/pandafe"


Mounting the Union FS : mount -t aufs -o exec,noplink,dirs="/media/mmcblk0p1/pandora/appdata/pandafe=rw+nolwh":"/mnt/pnd/pandafe=rr" none "/mnt/utmp/pandafe"


[sUCCESS]--- Mount the PND ----------


[ START ]--- Starting the application (bin/pandafe ) ----------


*** glibc detected *** ./bin/pandafe: free(): invalid pointer: 0x00171da8 ***


/usr/pandora/scripts/pnd_run.sh: line 519: 4307 Aborted "./$EXENAME" $ARGUMENTS


[ FAILED]--- Starting the application (bin/pandafe ) ----------


[ 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 ----------


rmdir: failed to remove `/mnt/utmp/pandafe': 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

 

[foxblock]

Yeah same here, it does create a few files in appdata, some of which seems to be bindings for certain emulators and a file called "preferences".


You can set a default ROM path in that file, but even after settings a valid path it still crashes with the same output...


(Also the extensive readme file (good work on that!) suggests I should not be forced to fiddle with config files manually...)

 

[nuhrin]

Hey folks, sorry I didn't get round to creating this thread myself, I've been uncommonly busy with a new baby on the way soon, among other things.


Thanks Gruso, for starting this thread and reporting this problem.


I am quite surprised by this crash, I didn't run into this at all during development or testing.


I have just a few minutes ago uploaded a new version to the repo with a few bug fixes (and the competition splashscreen, which I have managed to miss):


http://repo.openpandora.org/?page=detail&app=package.pandafe


Can you remove your appdata/pandafe folder, download this update from the repo and try again?


Also, what firmware version are you running? I'd like to try to recreate the problem, of course.

 

[nuhrin]

If anyone has been able to run this successful, please drop a note and say so here, along with your firmware version if possible. I'm not sure at this point whether this startup crash is an isolated or widespread problem.


Boy, sure hope it doesn't work just for me though...

 

[nuhrin]

Also the extensive readme file (good work on that!) suggests I should not be forced to fiddle with config files manually...

Indeed, it should not be necessary to edit any config by hand, just possible.

 

[gruso]

Deleted appdata and installed new version, still no go unfortunately. Behaviour and output is the same as before. (Strangely, this version also launches the readme along with the app).


The results are the same under SuperZaxxon b1 (default kernel) and HF7b2.

 

[Liboicl]

Same behavior on HF6b1.


If you release the source code, the readme said you were planning on it, I can help you find the cause.

 

[nuhrin]

Thanks for the extra info. Hmm, very strange. All I can think is that I must have introduced a dependency on something non-standard that's on my own system. I will reflash my system tonight with stock SuperZaxxon b1, HF7b2, and HB6b1, testing with an empty SD card containing only my /pandora/apps/pandafe.pnd. Surely I will run unavoidably into this bug if I do all that, given that at least three of you have seen it consistently.

Strangely, this version also launches the readme along with the app).

Ha, yeah. I did that on purpose deciding it was probably best if I encouraged it being read at least once since a little context for the program goes a long way to understanding how to use it. Not that anyone can much appreciate that if its borked. It only opens the readme if it hasn't previously been shown this way (appdata/pandafe/.readme_shown doesn't exist). If people consider this bad form I can certainly remove that behavior.

If you release the source code, the readme said you were planning on it, I can help you find the cause.

If I am unable to reproduce the problem tonight from my above tests I will perhaps upload the current source and take you up on your kind offer. I still need to add license headers and to merge a couple libraries (of mine) into the main tree to make the build less confusing, but that certainly doesn't prevent reading.


The particular error reported:

*** glibc detected *** ./bin/pandafe: free(): invalid pointer: 0x00171da8 ***

strikes me as being probably related to GLib (not to be confused with glibc) code generated by Vala double-freeing a string/gobject. Should be reasonably trivial to fix, if I can just reproduce it...

 

[nuhrin]

Ok, I found and fixed the problem. Updated version is on the repo.


It seems that libpnd changed the pnd_disco_t struct sometime since the last time I updated my firmware (early HF6). I wrote a wrapper around libpnd so that I could call into from vala, and the correspnding struct definition there was mismatched which was what caused the incompatible pointer error when instances of the struct were freed. Simply adding the new struct fields (pnd/app version information) to my wrapper and recompiling fixed the problem.


I tested with the latest HF6 from http://www.openpandora.org/downloads/Zaxxon-HF6.zip and everything works as expected. I didn't test with any later firmware, though there have been no further changes to pnd_disco_t in the libpnd repo so I'm fairly confident it should work just fine.


Its a bummer that this didn't surface till so late in the week, but I guess thats what I get for not updating off an alpha firmware for ages. :rolleyes:


Though I imagine not having a working app till now rather sinks me in the competition, this has been a lovely chance to start participating with the community here. I hope you all get the chance to try out my work over the new few weeks and let me know what you like or hate about it. I'm quite interested to hear your suggestions.

 

[spn-x]

Is it possible to use temper as the pce emulator ? I can only choose mednafen and that one doesn't work for me.

 

[Sigma]

Pandafe does work with HF6 now but does not work with Superzaxon (latest beta)


I do like the Frontend and think it great having 1 program for all the emu's.


Did something myself with wahcade but it didn't work with pnd files so good this Frontend seems to be one we need.


Keep on the work, you can get some votes from me


some suggestions for new features:


- easy way to Change background to a custom one for each emu, so when I pick snes I get a mario/zelda background


- Maybe a option to play background sound (to get that arcade frontend feeling)


- Touch controls (although I prefer buttons but maybe someone else prefers Touch controls)

 

[skeezix]

lindpnd structs have never changed, beyond adding memebrs to the 'end'; ie: if your'e assujming struct size, and packing them in an array, it could possible be a problem; however, libpnd includes alloc/dealloc type functions for such purposes, as well as lists, so shoudlnt' be a problem.


There've been a couple parallel libpnds where other people have pulled it, changed it and used their version, then submitted patches upstream, and I've rearranged their patches so as struct changes go to the end; but if you used someone elses interim libpnd, it could have run into member location changes.


Or perhaps something slipped through the fcracks.. I'm pretty anal about such things, but if a member got injected into the middle, please let me know which so I can examine the history.


(Also note, you might want to use struct member getter functions to avoid a problem in the future, though I agree, they're cumbersome and I tend not to use them either


So let me know more information (I just popped into thread, will go read..), so I can fix up any problems or we can find the source troublemaker


jeff


Hmm, taking a look at current.. I notice package_ stuff is at the end:


88 char *package_version_major;


89 char *package_version_minor;


90 char *package_version_release;


91 char *package_version_build;


But up at the top, package-id got injected:


61 char *package_id;


If thats a new one, that coudl be a problem shuffling the whole struct down a few bytes; is that the one? I'll have to check back and figure out what to do if so .. bump it to the end and risk breaking others, but being 'correct'...


I wonder if this was the patch in question:


http://git.openpandora.org/cgi-bin/gitweb.cgi?p=pandora-libraries.git;a=blobdiff;f=include/pnd_discovery.h;h=237ef6225339996db6b4bfc86fe13ab24f73441c;hp=d59c87e5cf2f0fc8408b49087626b632e48674e3;hb=b2aaaf39eef7bcc2bfa000fbdb9f72e6d0f656c8;hpb=cdaa163638fe57d9616e46fbbb79d1c20090ecbb


If thats the culprit, twas back in May. Do I bump the package_id to bottom, risking a few apps, or just leave it at this point?

 

[Sigma]

Found something interesting, when I run pandafe from:


/pandora/apps (hf6 and hf7) or /usr/pandora/apps (superzaxxon) then it works, when I run it from my fat formated SDHC card /pandora/apps/ it won't run I don't know why I think it has something to do with security rights strange..

 

[nuhrin]

Is it possible to use temper as the pce emulator ? I can only choose mednafen and that one doesn't work for me.

Hmm, I honestly wasn't aware of Temper before now. Happily, it does seem to accept the rom path on the command line, though the script run by the pnd app does not (temper.sh). To get it to work with Pandafe you can either:

1. add Temper to the TurboGrafx-16 platform through Pandafe itself, setting a custom command of: op_runfbapp ./temper "$@"
   
2. download the Temper program definition and updated turbografx16 platform definition I created to test this, and place in appdata/pandafe/Program and appdata/pandafe/Platform, respectively
   

depending on your comfort/interest in trying out the definition editing aspect of Pandafe. I'll include the Temper program definition in my next release.


Oh, and why doesn't mednafen work for you? Do you have it installed? Does it give an error?

 

[nuhrin]

Pandafe does work with HF6 now but does not work with Superzaxon (latest beta)

Found something interesting, when I run pandafe from: /pandora/apps (hf6 and hf7) or /usr/pandora/apps (superzaxxon) then it works, when I run it from my fat formated SDHC card /pandora/apps/ it won't run I don't know why I think it has something to do with security rights strange..

The new build does in fact work with both HF7 and SuperZaxxon. I confirmed both late last week and am currently running SuperZaxxon Beta 2 myself, (from pandora/apps on a fat32 formatted card).


The SDHC card involvement is indeed curious. What is the actual failure behavior? Does it crash or just not function as expected? Its certainly possible you've found a different bug... Can you try removing (or renaming) appdata/pandafe and rerunning?

I do like the Frontend and think it great having 1 program for all the emu's. Did something myself with wahcade but it didn't work with pnd files so good this Frontend seems to be one we need. Keep on the work, you can get some votes from me

Thanks for that. I will be glad to keep supporting and working on this as long as others are indeed using it.

some suggestions for new features: - easy way to Change background to a custom one for each emu, so when I pick snes I get a mario/zelda background

This is actually something I'd always intended to add but ended up cutting when time got short. I'll try to work on this for a near term release since I've got a partial implementation already in place.

- Maybe a option to play background sound (to get that arcade frontend feeling)

Hmm, I imagine this wouldn't be too hard to add, I can look into it. I find background music irritating in most situations, so it never occurred to me to support.

- Touch controls (although I prefer buttons but maybe someone else prefers Touch controls)

Touch controls being not at all present was an actual design goal; I wanted to focus on making the everything possible through dpad/button-based interface. Also, the interface is 100% custom (no toolkit libs, etc), consistent and *pleasant* touch support is going to be a lot of work. Still, I suppose if there is sufficient demand then I will look at adding this. Do you have any suggestions about how this might work effectively?


Thanks for all your feedback Sigma, I really appreciate it.

 

[nuhrin]

lindpnd structs have never changed, beyond adding memebrs to the 'end'; ie: if your'e assujming struct size, and packing them in an array, it could possible be a problem; however, libpnd includes alloc/dealloc type functions for such purposes, as well as lists, so shoudlnt' be a problem.


There've been a couple parallel libpnds where other people have pulled it, changed it and used their version, then submitted patches upstream, and I've rearranged their patches so as struct changes go to the end; but if you used someone elses interim libpnd, it could have run into member location changes.


Or perhaps something slipped through the fcracks.. I'm pretty anal about such things, but if a member got injected into the middle, please let me know which so I can examine the history.


(Also note, you might want to use struct member getter functions to avoid a problem in the future, though I agree, they're cumbersome and I tend not to use them either


So let me know more information (I just popped into thread, will go read..), so I can fix up any problems or we can find the source troublemaker


jeff


Hmm, taking a look at current.. I notice package_ stuff is at the end:


88 char *package_version_major;


89 char *package_version_minor;


90 char *package_version_release;


91 char *package_version_build;


But up at the top, package-id got injected:


61 char *package_id;


If thats a new one, that coudl be a problem shuffling the whole struct down a few bytes; is that the one? I'll have to check back and figure out what to do if so .. bump it to the end and risk breaking others, but being 'correct'...


I wonder if this was the patch in question:


http://git.openpando...b79d1c20090ecbb


If thats the culprit, twas back in May. Do I bump the package_id to bottom, risking a few apps, or just leave it at this point?

The libpnd change that bit me was most certainly this one: http://git.openpandora.org/cgi-bin/gitweb.cgi?p=pandora-libraries.git;a=commitdiff;h=2948aa122ac3cf51256c8a28b5966aba3607374b


I don't think though that the problem I ran into necessarily represents a problem in libpnd, but rather just my vala vapi binding (vala<->c-header bridge) for pnd_discovery.h being out of date after the change, and also probably a poor vapi design on my part.


Because of the way my binding is designed (struct members are explicitly repeated, with char* mapped to string, and uint mapped to explicit flags definition, etc), I think I ended up with mismatched pointer sizes in the pandora-glib wrapper vs libpnd.


I may be able to fix this by not explicitly defining each member in the vapi file, and/or by treating pnd_disco_t on the vala side as a class rather than a struct. The trick is that the size of a pnd_disco_t instance is defined at compile time rather than runtime, and so my wrapper library might have a hard time supporting multiple versions of libpnd and still be able to work with instances of pnd_disco_t.


I agree that using member getter functions would be more ideal in my situation, though I don't see any specifically for pnd_disco_t members. Do you mean I might should use the pnd_pxml_get_* methods? This might work, though then I'd have to essentially reimplement pnd_disco_search and call pnd_pxml_fetch myself for each pnd.


So ideally I guess I would like to see maybe one or both of the following added to libpnd:

• pnd_disco_get_* methods in pnd_discovery.h for each pnd_disco_t member, taking a void* handle/reference as input. Perhaps define pnd_disco_handle, as with pxml, just as long as this is really void*.
  
• pnd_disco_search variant that returns a list of pnd_pxml_handle instances, rather than a list of pnd_disco_t instances.
  

In any case, I will try and look for a good solution on my side that involves no libpnd changes.


Thanks for taking the time to consider and discuss this!

 

[Sigma]

a reply on the problems I have:


When I start Pandafe from my SD card it starts an crashes on the splash screen with the rebirth competion logo.


I've delete the appdata directory but that didn't work.


so then to see what happens when you start teh program I mounted the pnd file with the pnd_run.sh script, then I


started the pandafe.sh from the commandline in /mnt/utmp/pandafe and that gave me the following error:


./pandafe.sh


bin/pandafe: error while loading shared libraries: libcatapult.so.0:


cannot open shared object file: No such file or directory


It could not load/find the library, I created a new pandafe.sh file (copy of the orginal file) and added the following line:


export LD_LIBRARY_PATH="{LD_LIBRARY_PATH:-"/usr/lib:/lib:./lib"}"


then I started the new script and pandafe started but got a crash on the splash screen (the same screen when I started the pnd from SD card)


but got an error on the commandline:


./pandafe.sh2


**


ERROR:arraylist.c:679:gee_array_list_real_get: assertion failed:


(_tmp1_ < _tmp2_)


./pandafe.sh2: line 23: 3552 Aborted bin/pandafe


there is something with the arraylist.c (don't know what it does but I think you'll know what it does)


hope you can solve this.

 

[nuhrin]

bin/pandafe: error while loading shared libraries: libcatapult.so.0:

I have lazily relied on pnd_run.sh to add the LD_LIBRARY_PATH to ./lib itself. I suppose I may as well just add it to the script...

./pandafe.sh2 ** ERROR:arraylist.c:679:gee_array_list_real_get: assertion failed: (_tmp1_ < _tmp2_) ./pandafe.sh2: line 23: 3552 Aborted bin/pandafe

This is essentially an "array index out of bounds" error coming from libgee (Vala/GLib collection classes). It definitely represents a bug in Pandafe, though unfortunately its rather hard to say what is triggering this.


It's rather strange that you've continued to have this problem after removing appdata/pandafe, since that recopies known working data files. Want to gather some more information?

• Can you post or send me a copy of the fresh appdata folder created just before the crash?
  
• Does pnd_cache file exist?
  
• Try removing pnd_cache and all the files within Program/ and Platform/, then retry. If this works then perhaps there is a problem parsing one of the Program or Platform definition files.
  
• What's the pandafe.pnd version? (only available in the PXML.xml atm)
  

Oh, and, is this only happening on Superzaxxon as you'd reported earlier? I tested with the 3.2 kernel last night and it worked fine for me, though obviously there could be other dragons lurking there somewhere.


If you want to try and get me the above extra info (including firmware/kernel used) I will try and recreate and fix the problem as soon as possible. I have a long, boring screen-share-based company meeting this in about 3hrs, which might be a good window.


Thanks for the further reports!

 

[Sigma]

• Can you post or send me a copy of the fresh appdata folder created just before the crash? will attach a tar file:
  
• Does pnd_cache file exist? No
  
• Try removing pnd_cache and all the files within Program/ and Platform/, then retry. If this works then perhaps there is a problem parsing one of the Program or Platform definition files.: When I remove all the files from the "Platform" folder Pandafe start !! but when I try to add a something the program crashes still no pnd_cache exists
  
• What's the pandafe.pnd version? (only available in the PXML.xml atm) : version 0.1.2,1
  

Oh, and, is this only happening on Superzaxxon as you'd reported earlier? I tested with the 3.2 kernel last night and it worked fine for me, though obviously there could be other dragons lurking there somewhere. It happens to every firmware I try.





Update: I tried a standard clean 1 GB SD card and found that Pandafe works, looks like something is wrong with my SDHC card I think hmmmm... strange will try to fix my SDHC 16 GB card, haven't had any problems with other pnd files so this is really weird, when I remove the files from platform dir then the apps starts..

appdata-clean.tar

 

[nuhrin]

• Can you post or send me a copy of the fresh appdata folder created just before the crash? will attach a tar file:
  
• Does pnd_cache file exist? No
  
• Try removing pnd_cache and all the files within Program/ and Platform/, then retry. If this works then perhaps there is a problem parsing one of the Program or Platform definition files.: When I remove all the files from the "Platform" folder Pandafe start !! but when I try to add a something the program crashes still no pnd_cache exists
  
• What's the pandafe.pnd version? (only available in the PXML.xml atm) : version 0.1.2,1
  

Oh, and, is this only happening on Superzaxxon as you'd reported earlier? I tested with the 3.2 kernel last night and it worked fine for me, though obviously there could be other dragons lurking there somewhere. It happens to every firmware I try.





Update: I tried a standard clean 1 GB SD card and found that Pandafe works, looks like something is wrong with my SDHC card I think hmmmm... strange will try to fix my SDHC 16 GB card, haven't had any problems with other pnd files so this is really weird, when I remove the files from platform dir then the apps starts..

Thanks for going to all that trouble. I tried using your attached appdata/pandafe folder: it worked for me.


Considering all the extra context you provided, I think at this point that your problem probably points to a bug in my pnd scanning. If not yet present, the pnd_cache file will be created the first time pnd details are needed, which happens on program definition parsing (itself triggered by platform parsing), or when browsing the Pandora platform if no other platforms are present. I imagine you can also trigger this problem if you remove all platforms (letting you start) and then browse into the Pandora platform.


I think probably (hopefully!) your 16GB card is just fine. It sounds like perhaps one or more of the apps you have on that card is triggering a bug or wrong assumption in my pnd discovery code. Looking through it the code now I see two places off hand where that libgee assertion error you reported might get triggered, where I didn't do my own list index checking because it appeared logically impossible for this to happen. That may (or may not) be the problem.


If you're feeling up to it you might try moving all your apps off the various search paths and see if you can start, then put them back bit by bit and see if you can find one that triggers the problem. Or, you might just post a list of all the apps you have on that card, including any non-pnds (ie just directories with pxml.xml files), so I can grab all those to see if I can recreate this.


I will see if I can trigger this by just crafting some test apps with funky weird pxml contents, which is probably a good exercise anyway likely to uncover some other bugs as well. I realize now, for example, that non-pnd apps won't launch correctly and silly pxml with no app id will trigger a (different) crash.