The Following 12 Users Say Thank You to iDont For This Useful Post: | ||
|
2012-06-26
, 19:25
|
|
Posts: 5,028 |
Thanked: 8,613 times |
Joined on Mar 2011
|
#262
|
The Following 5 Users Say Thank You to Estel For This Useful Post: | ||
|
2012-06-29
, 14:10
|
Posts: 268 |
Thanked: 1,053 times |
Joined on May 2010
@ The Netherlands
|
#263
|
Thanks a lot, iDont! I've updated to new busybox from day first, and indeed, I don't have anything to report.
As for busybox-thumb - maybe it's good idea to sent it to freemangordon, for inclusion in thumb repository?
The Following 4 Users Say Thank You to iDont For This Useful Post: | ||
|
2012-07-18
, 06:14
|
Posts: 2,225 |
Thanked: 3,822 times |
Joined on Jun 2010
@ Florida
|
#264
|
As of now there is just one issue with busybox-power: when ash is killed -for the lack of a better term- "unnicely", there is a small chance ~/.ash_history could get garbled up. ...
The Following 6 Users Say Thank You to Mentalist Traceur For This Useful Post: | ||
|
2012-07-19
, 18:36
|
|
Posts: 4,118 |
Thanked: 8,901 times |
Joined on Aug 2010
@ Ruhrgebiet, Germany
|
#265
|
The Following User Says Thank You to peterleinchen For This Useful Post: | ||
|
2012-07-20
, 07:15
|
Posts: 1,808 |
Thanked: 4,272 times |
Joined on Feb 2011
@ Germany
|
#266
|
If you're referring to the bug I think you're referring to, in my experience, when it has happened, I ended up with lines of XML as my 'shell history' instead of actual commands. Suggesting that at some point the wrong file got copied over into .ash_history. I'll be honest, I know nothing about how 'FILE' is implemented, on our device or otherwise, but I would think that, if a FILE pointer's value got changed, it would either point to a different file, or to a non-existent file, depending on the exect bytes at the newly pointed to location.
C being C would assume you knew what you were doing and would interpret the data at the new location as a typical FILE struct (I think it's a struct, idk). If it was a corner case resulting from some rarely occuring overwrite of a FILE pointer, the compiler would probably not catch it?
(If I am wrong, if someone could let me know how it actually works, it would be greatly appreciated.)
The Following 3 Users Say Thank You to reinob For This Useful Post: | ||
|
2012-07-20
, 13:36
|
Posts: 2,225 |
Thanked: 3,822 times |
Joined on Jun 2010
@ Florida
|
#267
|
The idea sounds good. But honestly the chances of a random FILE* pointer (e.g. one having been used for cat'ing an XML file..) being overwritten so as to end up having the exact value of the FILE* pointer of .ash_history are close to zero.
I'm not 100% sure now but I think busybox keeps the history in RAM until it exists, where the history file is actually written to. Meaning [ assuming that what I say is true ] that at some point, for some reason, the RAM buffer is being overwritten (partially) with other data (XML, whatever).
The Following 4 Users Say Thank You to Mentalist Traceur For This Useful Post: | ||
|
2012-07-20
, 20:52
|
Posts: 1,808 |
Thanked: 4,272 times |
Joined on Feb 2011
@ Germany
|
#268
|
Well, you don't need a random FILE* to get the value of the .ash_history FILE*, which would indeed be vanishingly unlikely. You'd just need the value of the .ash_history FILE* to get the value of any random file on the system - a much more likely possibility.
I wasn't suggesting, as I think you interpreted, that by using the shell to manipulate file X, I somehow managed to cause that file's pointer to point to the .ash_history file. Rather, I was saying that the .ash_history file struct may have gotten overwritten by random 'garbage' data - and the depending on your luck it might either end up with a handle to a non-existing file, perhaps explaining the 'blank' root user shell history I got in my last instance of the bug, or the file handle at the C FILE struct might end up being one pointing to an actual file somewhere - explaining why people have different experiences with what file contents end up overriding the shell history.
Either way though, you know C more than me, so you probably got more insight into this than me.
The Following 2 Users Say Thank You to reinob For This Useful Post: | ||
|
2012-07-20
, 23:09
|
|
Posts: 4,118 |
Thanked: 8,901 times |
Joined on Aug 2010
@ Ruhrgebiet, Germany
|
#269
|
The idea sounds good. But honestly the chances of a random FILE* pointer (e.g. one having been used for cat'ing an XML file..) being overwritten so as to end up having the exact value of the FILE* pointer of .ash_history are close to zero.
Well, a FILE structure essentially contains a file handle (so to speak, the kernel's equivalent of C's FILE) as well as some pointers to various read/write buffers, etc.
I'm not 100% sure now but I think busybox keeps the history in RAM until it exists, where the history file is actually written to. Meaning [ assuming that what I say is true ] that at some point, for some reason, the RAM buffer is being overwritten (partially) with other data (XML, whatever).
|
2012-07-21
, 03:38
|
Posts: 2,225 |
Thanked: 3,822 times |
Joined on Jun 2010
@ Florida
|
#270
|
But another thing is that also bb on its own screws the FILE pointer itself, pointing to any space in RAM (reading will be allowed out of non-belonging space?). This would also explain the totally random content of history.
The Following 4 Users Say Thank You to Mentalist Traceur For This Useful Post: | ||
Initial thumb ISA support is also available in busybox-power's source tree, if you want to compile it yourself. You'll need a thumb-enabled target in Scratchbox (instructions). Once the target is set up, compiling is as simple as running `sh build.sh thumb` from your local busybox-power git repository.
Furthermore, a new busybox-power version has been pushed to Maemo's repositories last Sunday. It's mostly a bugfix release, incorporating upstream's hotfixes, but it also has a nice new feature for the vi users amongst us: when vi is ran in a terminal emulator (i.e. X Terminal), your terminal's output is restored after closing vi.
Lastly, I must say that the transition from BusyBox' 1.19.x to 1.20.x series went extremely smooth; there have been zero new issues reported since busybox-power 1.20.0power1 has been released!
-
As of now there is just one issue with busybox-power: when ash is killed -for the lack of a better term- "unnicely", there is a small chance ~/.ash_history could get garbled up. I still can't find any problematic code in the source, any help is greatly appreciated. Look for save_history() in libbb/lineedit.c in upstream's latest stable BusyBox release. Unless someone else finds an issue in the source, I'm assuming the issue is not related to BusyBox itself.
Currently, history saving is handled as follows: all new history is appended to ~/.ash_history. After that, the history file gets reloaded via load_history(), which effectively trims it to n lines (n = MAX_HISTORY). Finally, the newly trimmed history is written out to ~/.ash_history.$PID.new, which will be moved to ~/.ash_history upon finishing writing it out.
Last edited by iDont; 2012-06-26 at 18:30.