>> From: Andrew Reilly <andrew-newsp...@areilly.bpc-users.org> I did not >> On the subject of memory limits and the like, what does "limits -a" say >> on your system?
> I tried "man limits" and all it would tell me is that it's a built-in > command.
DESCRIPTION The limits utility either prints or sets kernel resource limits, and may optionally set environment variables like env(1) and run a program with the selected resources. Three uses of the limits utility are possible:
etc.
It's in /usr/bin on my system. Yes, some shells (csh) have their own, builtin, called "limit". Nothing is stopping you from looking this stuff yourself, of course.
You're just doing this for my amusement, now. Good job.
> I refuse to type some command that I don't understand, such as > 'rm **/*', into the shell just to see what happens when I do, just > because somebody on the net tells me to try it. I don't obey drug > dealers asking me to "just try it", and I don't obey you asking me "what > does ... say on your system". Until I know otherwise, it's like that > path of wild mushrooms I found growing next to a tree at my local bank: > Might be delicious to taste, but it's not worth the risk. Oh by the way, > here's a photo of one of the mushrooms. If you saw this, would you take > a chance on it?
(Robert Maas, http://tinyurl.com/uh3t) wrote: >> From: George Neuner <gneun...@comcast.net> >> The warning says: "Chip supports SSE2, but could not find SSE2 core." >> Despite the use of the term "core", the message suggests the problem >> is software rather than hardware. I'm guessing that "core" in this >> context refers to a device driver.
>Nope. CMUCL requires an executable file plus a "core" file. Here are the two:
>> pwd >/home/users/rem/Tmps/TmpCmucl/bin >> ls -l >387 -rwx------ 1 rem user 334878 Mar 10 2009 lisp*
>> pwd >/home/users/rem/Tmps/TmpCmucl/lib/cmucl/lib >> ls -l *core >24982 -rw------- 1 rem user 25432064 Mar 10 2009 lisp-x87.core
Ok, it may not be a "driver" in the OS sense, but the x87 is not memory mapped, so the existence of this file still verifies my supposition that the problem is software.
>>>>> "George" == George Neuner <gneun...@comcast.net> writes:
George> On Sun, 01 Nov 2009 01:33:26 -0700, seeWebInst...@rem.intarweb.org George> (Robert Maas, http://tinyurl.com/uh3t) wrote:
>>> From: George Neuner <gneun...@comcast.net> >>> The warning says: "Chip supports SSE2, but could not find SSE2 core." >>> Despite the use of the term "core", the message suggests the problem >>> is software rather than hardware. I'm guessing that "core" in this >>> context refers to a device driver. >> >> Nope. CMUCL requires an executable file plus a "core" file. Here are the two: >> >>> pwd >> /home/users/rem/Tmps/TmpCmucl/bin >>> ls -l >> 387 -rwx------ 1 rem user 334878 Mar 10 2009 lisp* >> >>> pwd >> /home/users/rem/Tmps/TmpCmucl/lib/cmucl/lib >>> ls -l *core >> 24982 -rw------- 1 rem user 25432064 Mar 10 2009 lisp-x87.core
George> Ok, it may not be a "driver" in the OS sense, but the x87 is not George> memory mapped, so the existence of this file still verifies my George> supposition that the problem is software.
This core file has no relationship to the core dump core file. This file (or lisp-sse2.core) is required by cmucl to work. It is basically the memory image for lisp. Without either of files, cmucl would not run at all.
GNU Midnight Commander 4.6.2 Virtual File System: tarfs, extfs, cpiofs, ftpfs, fish, smbfs With builtin Editor Using system-installed S-Lang library with termcap database With subshell support as default With support for background operations With mouse support on xterm With internationalization support With multiple codepages support Data types: char 8 int 32 long 64 void * 64 off_t 64 ecs_char 8
By the way, several weeks ago I tried to type:
> mv sourceFile destinationDirectory/
but accidently hit the 'c' key next to the 'v' key on standard QWERTY keyboard, resulting in typing by mistake:
> mc sourceFile destinationDirectory/
That threw me into something that looked vaguely like DIRED except that it didn't seem to be emacs-based so ctrl-X ctrl-C wouldn't exit from it. I spent a half hour looking through the 'man mc' pages, trying to find out how to gracefully exit from the program, but couldn't find the needed info. Finally, totally frustrated, I gave up and did something rather drastic: I ran 'ps' to find out the process number and then used the 'kill' command to FORCIBLY KILL IT!!
> > I spent a half hour looking through the 'man mc' > > pages, trying to find out how to gracefully exit from the program, > From: Vassil Nikolov <vniko...@pobox.com> > I have never used `mc', but I got curious, so I searched for `quit' > in the man page. However, do you have an `f10' key?
Yes. When I press it, it transmits the following sequence of five characters:
Making that one keystroke be the contents of a CMUCL string, convert to hxd: * (map 'list #'(lambda (ch) (format nil "~x" (char-code ch))) "^[[28~")) ==> ("1B" "5B" "32" "38" "7E")
Now is there any particular reason to believe that sequence of five characters is in-combo specially meaningful to 'mc'?
Now since the four arrow keys transmit similar-looking sequences: uparrow ^[[A downarrow ^[[B rightarrow ^[[C leftarrow ^[[D and the shell actually understands them and does the "right" thing (up/down arrows navigate to previous/later shell commands, left/right arrows move within a single command-line being edited) it's plausable that the function-number keys might likewise do something meaningful when typed at some Unix applications/utilities.
By the way, it's my understanding that those same sequences of characters when sent *from* the host *to* the VT100 terminal (emulator) are screen-edit cursor-motion commands. I discovered some of them when scraping 'lynx' output via ext:run-program.
> From: r...@rpw3.org (Rob Warnock) > As I have said several times already in this thread, 32-bit ("i386") > CMUCL-19c and CMUCL-19e work just *fine* on 64-bit versions of > both FreeBSD 6.2 and Linux 2.4.26 & 2.6.{7,18,20}, and IME have > *no* problems with long-running processes that GC *thousands* of times. > It *does* require that the 32-bit compatibility libs be installed, > but if it runs at all then that has been done. [The only 32-bit libs > it absolutely requires to run & GC are "libc" & "libm".]
OK, thanks for eliminating one spurious worry. It must be something a lot more subtle than what version of CPU things run on. I'm still looking to a difference between this pre-reslease version and the official final release regarding the types of page-fault signals that are generated by the system to be intercepted by the application, which CMUCL uses to make GC more efficient.
> But CMUCL-19f and/or FreeBSD 7.1 are another matter entirely...
Except that both 19c and 19f exhibit the *same* crash-on-second-GC bug, so whatever is different from 19c to 19f is likely moot.
> Look, on the x86 architecture, CMUCL current exists *ONLY* in a > 32-bit version, so there *isn't* a 64-bit version to use in any case. > But as I've said above [and before], the 32-bit x86 build works > just fine on x86-64 hardware with a 64-bit operating system that > has 32-bit compatibility libs installed. So -- prior to CMUCL-19f > and prior to FreeBSD 7.x -- there was nothing "chancy" about it > at all. It "just worked".
But that does't explain why 19c and 19f exhibit the *same* crash here.
> I have not looked into it closely, and the release notes for > CMUCL-19f don't mention it, but ISTR hearing something about some > changes to signal handling needed for FreeBSD 7.1, and those may > have made it into CMUCL-19f, and there might be some problem with > the GC resulting from that.
Specifically page-fault signals is the rumor I heard.
> [I can't suggest more, since I don't have any FreeBSD 7.x > machines to experiment on.]
You have rawbw.com any time you want to ask the admin to give you a 2-week free-trial shell account here. I posted the URL for the relevant Web page, and excerpts, but apparently you missed it so I'll repeat here:
<http://www.RawBandwidth.com/services/res.html> Try our Personal PPP account FREE for 2 weeks with no strings attached. We don't even take your credit card number! .. Personal PPP/Shell (extra Web space and CGI), $25.95/mo. Network Shell (no dialup), $15.00/mo. Personal Shell (terminal dialup), $19.95/mo. (what I had until 2009.Nov.04 when RawBandwidth outsourced all dialups to no longer include terminal dialup. Now I use PPP + NiftyTelnet)
2 weeks should be plenty long for a CMUCL/internals/FreeBSD expert such as you to diagnose this problem and get ideas towards a fix.
> I do know that for x86/FreeBSD the conservative generational GC > is now the only version supported,
I assume that statement also applies to amd/FreeBSD by means of 32-bit compatibility libraries?
Hmm, here's something I hadn't considered before: Both amd/FreeBSD and CMUCL 19c/19f might be perfectly fine, but the 32-bit compatibility libraries installed here might *not* be the correct version for FreeBSD 7.1, which would explain why 7.1 everywhere else works fine with CMUCL but not here. Tell me the names of the files to look for, and the 'where's command should show them. Based on what you said above, I'm guessing:
> whereis libc
libc: /usr/ports/x11/kdelibs4/work/kdelibs-4.3.1/kjs/wtf/unicode/libc ^^^ (-: what the fuck?? :-)
> whereis libm
libm:
Hmm, libm seems to be missing here. Could *that* be the problem, why regular stuff works fine, using libc, but GC which needs libm crashes??
> and that that GC *does* use Unix signalling of page-fault write > traps as a hardware write barrier,
Ah, that's a better explanation than was posted previously, thanks.
> so it is certainly possible that the 32-bit-on-64-bit handling of > memory fault signals is different than 32-bit-on-32-bit or > 64-bit-on-64-bit.
Especially if libm is missing??
> (room) and (room t) should provide some helpful information to you.
* (room) Dynamic Space Usage: 85,808 bytes (out of 512 MB). ..
Ah, thanks. I had vaguely heard of that many many years ago, but didn't have access to any version of Common Lisp that provided that function, so it slipped my mind. So in theory an application could divert that output to a string-stream then parse it to glean the relevant information and use that info to decide whether it's just about time to do that one and only usable GC or whether to wait a while longer. I wish I had known that when I was doing the emergency rescue of my GeoCities files. But I got by without it, just running until it crashed, never doing any GC at all, setting maxheap to 1024 MB, saving to disk every major batch, and re-starting from the end the last saved batch after every run-out-of-heap crash.
I wish I had been able to use 'room' in MACL 1.2.2 when I was writing my *huge* file-maintenance utility that sorted a listing of *all* my files on hundreds of diskettes, all on a Mac Plus with only 1MB RAM. It first collected batches of as much as would fit in memory. With no way to anticipate a GC, but a tricky way to tell *after* a GC had happened, what I did when loading data into memory to build a sorting batch was to load *twice* as much data as I really needed, discarding pointers to half of it, so that after a GC happened I knew that the heap was about half full, plenty of room to sort that batch of data and write to disk. After the master list of files was broken into sorted blocks like that, then I had about fifty separate merge-run files on the disk, but was allowed only about 25 files open at any one time, so I did multiple passes of a 20-way merge to reduce the fifty-some-odd files down to a single final-output sorted file.
Oh by the way, I got the idea for the *overall* file-maintenance system from the COBOL compiler that Four Phase Inc. wrote to run on their own custom 24-bit mini-computers cirac 1970, which had such small address space that the entire COBOL compiler wouldn't fit in RAM at one time, so it had to be broken into overlays, but also all the temporary data for compiling a large COBOL program such as symbol table wouldn't fit in RAM either. So the overall compiler consisted of alternating merge-sort and collate passes. First do syntax analysis and write file of symbols defined or used. Then sort them into alphabetical order by symbol so that all definitions/uses of same symbol are adjacent. Then pass that file matching definitions/uses of each symbol which are adacent to make sure all symbols are defined before used. Then another sort/merge to rearrange all the data into a different sequence whereby collating would accomplish the next compiler pass, of matching usages of symbols with details of their definitions, so that appropriate object-code could be generated. The last pass sorted all that object-code into source sequence so that the executable binary could be written. Ingenious, and I was hired to maintain that COBOL compiler, i.e. fix bugs in this ingenious COBOL compiler, which is why I understand the innerds, and could apply the idea to my file-maintenance application.
So anyway, my file-maintenance application worked like this: - Run a directory-making function, whereby I manually looked through all my diskettes to see which were write-enabled, indicating that I had changed them since the last directory was listed. I write-lock each and put it in, the program checks to make sure the WDEF virus isn't present, but if present then it asks me to temporarily write-unlock so that it can remove the WDEF resource from the Desktop on that diskette, then write-lock and check again. Finally, recursively explore the directory and write it out as a nested s-expression showing the file hierarchy. - Read all the nested-s-expression directory files in and write out a temporary of each flattened to repeat all the directory path in every line of output, writing *all* these flattened lines to one (1) temporary output file. - The sort-merge algorithm described above to put into alphabetical order by filename. - Collate-pass to find how many versions of each file exist, and recommend older backups to delete so that I have exactly three copies of each file scattered among my many diskettes. Write all these delete-requests to new temporary file. - The sort-merge algorithm again on this file of delete-requests, now putting this subset back into diskette sequence. - Now read through this list of diskette-sequence delete-requests, asking me to write-unlock each so that the program can automatically delete the files per the delete requests. Then I write-lock it again, and the program automatically creates a new nested-s-expression listing of that diskette to replace the one it had been working from earlier. It also updates a master listing of how much empty space there is on each diskette, so that I can plan re-using now-partially-empty diskettes to save new backups on.
> Note that the default in CMUCL is to trigger a GC when ~12 MB of > new data has been allocated since the last GC, so if it's failing > on the second GC after process start that's not likely to be a > "filling up" issue...
Yup, your logic on that point agrees with mine. The GC bug is unrelated to how much of the 512MB or 1024MB allowed heap is actually used at the time of the second GC.
Wouldn't it be funny if libm missing was the whole problem? The admin did a rather hasty installation of any Unix applications that various users depended on, to encourage them to switch to the new shell machine, and he could have very easily overlooked something that CMUCL needs *only* when a second GC happens. (Better
> Now is there any particular reason to believe that sequence of five > characters is in-combo specially meaningful to 'mc'?
In general, keypresses of function keys on terminals map to such escape sequences. So yes, one would of course expect mc to understand them like other terminal applications. As such sequences vary a bit from terminal to terminal, there is an abstraction layer us dwellers in the present use for such things - terminfo (or the older termcap).
However, that specific sequence does not match the typical terminal escape sequence for F10 which is ^[[21~
So you need to find a TERM env var setting that accurately corresponds to whatever the hell stone-age terminal you have, one that sends ^[[28~ instead of ^[[21~ for F10 (or verify that you were really pressing F10)
A quick glance at the terminfo database source (nowadays bundled in ncurses sources in misc/terminfo.src) shows that there ARE terminals that use ^[[28~ for F10 (non-exhaustive, look them up your goddamn self):
NCSA Telnet for Macintosh TERM=ncsa-m (not ncsa-vt220, since that uses ^[[28~ = F15),
hewlett packard 700/44 in HP-PCterm mode TERM=hpansi
Questar 303 with PC keyboard TERM=bq300-pc
Texas Instruments 916 TERM=ti916
Texas Instruments 928 TERM=ti928
With the correct TERM setting for your terminal or terminal emulator, mc should recognise an F10 keypress as F10.
The Sun, 08 Nov 2009 12:32:25 +0000, David Golden wrote:
> With the correct TERM setting for your terminal or terminal emulator, mc > should recognise an F10 keypress as F10.
That is a oversimpification. The terminal emulator itself often overides function key's. If thermial emulator grabs it before ncurses sees it it there is little you can do. You can of cource run it fullscreen as a text teminal.
John Thingstad wrote: > The Sun, 08 Nov 2009 12:32:25 +0000, David Golden wrote:
>> With the correct TERM setting for your terminal or terminal emulator, mc >> should recognise an F10 keypress as F10.
> That is a oversimpification. The terminal emulator itself often overides > function key's. If thermial emulator grabs it before ncurses sees it it > there is little you can do.
Well, yeah. xfce4-terminal grabs F10 for menu access, for example (though you can turn that off in the shortcuts tab in its preferences, thankfully). However, I don't think that was the problem he was having in this instance since he was apparently able to see the escape sequence being generated.
|
