December 2020 - Pharo-dev - lists.pharo.org

MoreVMs 2021 : Workshop on Modern Language Runtimes, Ecosystems, and VMs

by Fabio Niephaus

============================================================================ Call for Extended Abstracts and Talks: MoreVMsâ21 5th International Workshop on Modern Language Runtimes, Ecosystems, and VMs Co-located with â¹Programmingâºâ21 March 22nd to 26th, 2021, Online, United Kingdom https://2021.programming-conference.org/home/MoreVMs-2021 ============================================================================ Following four previous successful editions, the MoreVMsâ21 workshop aims to bring together industrial and academic programmers to discuss the design, implementation, and usage of modern languages and runtimes. This includes aspects such as reuse of language runtimes, modular implementation, language design, and compilation strategies. By bringing together both researchers and practitioners, the workshop aims to enable a diverse discussion on how languages and runtimes are currently being utilized, and where they need to improve further. In addition to conventional workshop-style submissions, MoreVMs also accepts (and encourages) submissions that present early-stage work and emerging ideas. Relevant topics include, but are definitely not limited to, the following: - Extensible VM design (compiler- or interpreter-based VMs) - Reusable components (e.g. interpreters, garbage collectors, ...) - Static and dynamic compilation techniques - Techniques for targeting high-level languages such as JavaScript - Interoperability between languages - Tooling support (e.g. debugging, profiling, etc.) - Programming language development environments - Case studies of existing language implementation approaches - Language implementation challenges and trade-offs - Surveys and usage reports to understand usage in the wild - Ideas for more predictable performance - Ideas for how VMs could take advantage of new hardware features - Ideas for how we should build languages in the future Workshop Format and Submissions ------------------------------- We welcome presentation proposals in the form of extended abstracts (2 to 4 pages long) and talk proposals (title and 400 words abstract) discussing new techniques, insights, experiences, works-in-progress, as well as future visions, from either an academic or industrial perspective. The extended abstracts and talk proposals, and if the speakers wish, their slides, will be published on the workshop's website. Alternatively, extended abstracts can be published as part of the companion of â¹Programmingâºâ21 in the ACM DL. Publication in the ACM DL is conditional on the acceptance by the program committee. Please note that MoreVMsâ21 is organized as an academic workshop, and as such, speakers will be required to register for the workshop. Author Instructions ------------------- Submissions should use the ACM `acmart` format: https://www.acm.org/publications/proceedings-template If you are using LaTeX, submissions should use the 'acmart' document class with the 'sigconf' option, and with a font size of 9 point. Please use the Libertine/Biolinum font family. Please include page numbers in your submission using the LaTeX command `\settopmatter{printfolios=true}`. All submissions should be in PDF format. Please also ensure that your submission is legible when printed on a black and white printer. In particular, please check that colors remain distinct and font sizes are legible. Submission Site: https://easychair.org/conferences/?conf=morevms21 Important Dates --------------- Extended abstract and talk submissions: 2021-01-13 Author notification: 2021-02-15 Camera Ready: 2021-02-26 Workshop: TBA (between 2021-03-22 and 2021-03-26) All deadlines are Anywhere on Earth (AoE), i.e. GMT/UTC-12:00 hour. Program Committee ----------------- Maya Armyanova, Google, Germany Maxime Chevalier-Boisvert, UniversitÃ© de MontrÃ©al, Canada Lukas Diekmann, King's College London, United Kingdom Charlie Gracie, Microsoft, Canada Daco Harkes, Google, Denmark Christian Humer, Oracle Labs, Switzerland Sophie Kaleba, University of Kent, United Kingdom Mikel LujÃ¡n, University of Manchester, United Kingdom Ana Milanova, Rensselaer Polytechnic Institute, United States Tobias Pape, Hasso Plattner Institute, University of Potsdam, Germany Tomoharu Ugawa, University of Tokyo, Japan Organizers ---------- Fabio Niephaus, Hasso Plattner Institute, University of Potsdam, Germany David Leopoldseder, Oracle Labs, Austria

Dec. 16, 2020

[ANN] Next Pharo Sprint: Dec 18

by Marcus Denker

We will organize a Pharo sprint / Moose dojo Dec 18 (this Friday). This is a bit earlier due to Christmas times. Goals of this sprint: - Fix issues from tracker https://github.com/pharo-project/pharo/issues This is a Remote Sprint, it happens on Discord. http://pharo.org/contribute-events We have added a Board to coordinate the work: https://github.com/orgs/pharo-project/projects/9 A list of all Pharo Event of the year an be found here: https://association.pharo.org/events

Dec. 14, 2020

Progress Report -> Refactoring Project - ( December 7 - 11 )

by EVELYN CUSI LOPEZ

Hi everyone, Last week I did these tasks: - Review Commander2, to migrate refactorings to use Commander2 we must create a decorator class using Calypso, now only exists a decorator with Spec2 (SpCommand). - Fix UI rename method issue ( https://github.com/pharo-project/pharo/pull/7978) - Fix undo refactoring issue ( https://github.com/pharo-project/pharo/pull/8051) - Review Refactoring2 - Start to fix Extract method issues. Tasks for this week: - Finish to fix Extract method issues. - Re-visit all the tests to use a classBuilder instead of string as much as possible. - Improve the refactoring model to support traits and slots. - Fix Push up refactoring issue #2656 ( https://github.com/pharo-project/pharo/issues/2656) - Fix Abstract instance variables issue ( https://github.com/pharo-project/pharo/issues/8100) Cheers, Evelyn

Dec. 14, 2020

Re: Call for Beta-testers Pharo ARM64 JIT

by Sven Van Caekenberghe

Hi, This is fantastic news on several levels - the new JIT itself, but even more the new approach, process, infrastructure and tests. (Sorry, but this is a long/techncal mail). A week ago I was one of the first people outside the development team to be able to test the new ARM64 JIT VM on hardware they did not even test on. In particular I used an Amazon AWS EC2 T4g.micro instance (1 GB) with Ubuntu Server 20.04.1 LTS. These machines use an ARM64 CPU (AWS Graviton2, Neoverse N1, Cortex-A76, ARM v8). https://aws.amazon.com/ec2/graviton/ https://aws.amazon.com/ec2/instance-types/t4/ https://en.wikipedia.org/wiki/Annapurna_Labs#AWS_Graviton2 ubuntu@ip-172-30-0-23:~/test$ uname -a Linux ip-172-30-0-23 5.4.0-1030-aws #31-Ubuntu SMP Fri Nov 13 11:42:04 UTC 2020 aarch64 aarch64 aarch64 GNU/Linux ubuntu@ip-172-30-0-23:~/test$ lscpu Architecture: aarch64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian CPU(s): 2 On-line CPU(s) list: 0,1 Thread(s) per core: 1 Core(s) per socket: 2 Socket(s): 1 NUMA node(s): 1 Vendor ID: ARM Model: 1 Model name: Neoverse-N1 Stepping: r3p1 BogoMIPS: 243.75 L1d cache: 128 KiB L1i cache: 128 KiB L2 cache: 2 MiB L3 cache: 32 MiB NUMA node0 CPU(s): 0,1 Vulnerability Itlb multihit: Not affected Vulnerability L1tf: Not affected Vulnerability Mds: Not affected Vulnerability Meltdown: Not affected Vulnerability Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl Vulnerability Spectre v1: Mitigation; __user pointer sanitization Vulnerability Spectre v2: Not affected Vulnerability Srbds: Not affected Vulnerability Tsx async abort: Not affected Flags: fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp ssbs My reaction after one hour ? Wow, wow, wow, this is incredible. It all just works and it seems pretty fast as well. I played with the vm/image for a couple of minutes and so far everything worked as expected and I had no crashes at all. The order of magnitude of 1 tinyBenchmarks is very similar to other (server) machines: "'1894542090 bytecodes/sec; 146296146 sends/sec'" "arm64" "'2767567567 bytecodes/sec; 258718969 sends/sec'" "macOS" "'1227082085 bytecodes/sec; 109422120 sends/sec'" "aws" "'2101590559 bytecodes/sec; 166532391 sends/sec'" "t3 lxd" Here is a benchmark in the HTTP space, how fast can ZnServer respond to multiple concurrent requests over the local network: $ ./pharo Pharo.image eval --no-quit 'ZnServer startDefaultOn: 1701' & $ ab -k -n 1024 -c 8 http://localhost:1701/small This is ApacheBench, Version 2.3 <$Revision: 1843412 $> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/ Server Software: Zinc Server Hostname: localhost Server Port: 1701 Document Path: /small Document Length: 124 bytes Concurrency Level: 8 Time taken for tests: 0.268 seconds Complete requests: 1024 Failed requests: 0 Keep-Alive requests: 1024 Total transferred: 317440 bytes HTML transferred: 126976 bytes Requests per second: 3814.45 [#/sec] (mean) Time per request: 2.097 [ms] (mean) Time per request: 0.262 [ms] (mean, across all concurrent requests) Transfer rate: 1154.76 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect: 0 0 0.0 0 0 Processing: 0 2 19.0 0 267 Waiting: 0 2 19.0 0 267 Total: 0 2 19.0 0 267 Percentage of the requests served within a certain time (ms) 50% 0 66% 0 75% 0 80% 0 90% 0 95% 0 98% 0 99% 42 100% 267 (longest request) That is 3800 req/s with 8 concurrent threads, each response 124 bytes. And the output document is dynamically generated each time ! Now a cached static binary document, first a small one (64 bytes): $ ab -k -n 1024 -c 8 http://localhost:1701/bytes This is ApacheBench, Version 2.3 <$Revision: 1843412 $> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/ Server Software: Zinc Server Hostname: localhost Server Port: 1701 Document Path: /bytes Document Length: 64 bytes Concurrency Level: 8 Time taken for tests: 0.214 seconds Complete requests: 1024 Failed requests: 0 Keep-Alive requests: 1024 Total transferred: 256000 bytes HTML transferred: 65536 bytes Requests per second: 4778.62 [#/sec] (mean) Time per request: 1.674 [ms] (mean) Time per request: 0.209 [ms] (mean, across all concurrent requests) Transfer rate: 1166.65 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect: 0 0 0.0 0 0 Processing: 0 2 12.3 0 207 Waiting: 0 2 12.3 0 207 Total: 0 2 12.3 0 207 Percentage of the requests served within a certain time (ms) 50% 0 66% 0 75% 0 80% 0 90% 0 95% 0 98% 5 99% 64 100% 207 (longest request) That is 4700 req/s Now a larger one, 1024 bytes: $ ab -k -n 1024 -c 8 http://localhost:1701/bytes/1024 This is ApacheBench, Version 2.3 <$Revision: 1843412 $> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/ Server Software: Zinc Server Hostname: localhost Server Port: 1701 Document Path: /bytes/1024 Document Length: 1024 bytes Concurrency Level: 8 Time taken for tests: 0.228 seconds Complete requests: 1024 Failed requests: 0 Keep-Alive requests: 1024 Total transferred: 1241088 bytes HTML transferred: 1048576 bytes Requests per second: 4484.93 [#/sec] (mean) Time per request: 1.784 [ms] (mean) Time per request: 0.223 [ms] (mean, across all concurrent requests) Transfer rate: 5308.34 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect: 0 0 0.0 0 0 Processing: 0 2 16.2 0 227 Waiting: 0 2 16.2 0 227 Total: 0 2 16.2 0 227 Percentage of the requests served within a certain time (ms) 50% 0 66% 0 75% 0 80% 0 90% 0 95% 0 98% 0 99% 41 100% 227 (longest request) Still 4400 req/s - 1024 requests finished in about 0.25 seconds, transferring 1Mb. These are really good numbers ! Of course, with an actual network between the client and the server, the numbers are much lower, but this localhost benchmark gives you an idea of the maximum speed that is theoretically possible. And under this load, the image+vm remained totally stable. Since then I started a public Zn HTTP server, Pharo 9 live on an ARM64 JIT VM: http://34.245.183.130:1701 http://34.245.183.130:1701/status http://34.245.183.130:1701/help I want to see how long it keeps running. You can test this for yourself. Idle load of the VM is also excellent: 0.3% CPU. Overall machine load is 0.00 ! I fiddled around a bit more the next day. Everything kept on going smooth, nothing unexpected happened. I could use the command line tools to save a new image, load several of my packages using metacello from github using a baseline and tonel, I could run all test suites just fine. Everything was just *fast*. I installed NeoConsole so that I could use telnet to get a REPL into a running image. A week later, the server Pharo image was still running fine. In summary: Great, great work and thanks again everyone for the effort. You (in particular Pablo, Guille, Esteban and the whole Pharo community) can be very proud of this achievement. Sven > On 12 Dec 2020, at 17:31, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > Dear happy Pharoers and others, > > Over the last months we have been working on the implementation of a MIT-licensed ARMv8 Just-In-Time compiler for Pharo VM. > We are very happy with the advance on this subject, as we have not only implemented a new backend but we have added more than 2500 > tests to the JIT, the primitives, code generation, plugins and the VM in general. In the process we fixed many problems. > It shows that following the roadmap that was decided during General assembly of PharoDays, we have been investing in the Pharo VM and that > our efforts are greatly paying off. > Also, we are generating a lot of documentation and improving the process to really democratize the development of the VM. > So Pharo is a better shape than ever on such matter and this opens a lot of possibility for the future. > > ## Call for Beta-Testers > > We would like to announce that a first version of our JIT backend is available for beta-testing for ARM Linux machines using Ubuntu. > We are now entering into a beta testing stage of the VM and the image in Ubuntu ARM 64. > We would like to invite you to our beta testing phase for the VM. If you're interested in participating, > please contact pablo.tesone(a)inria.fr. > > The following sections give more details of the current status, and the following steps including Apple Silicon, Windows ARM64 and Linux Open Build System support. > > ## Current Status > > Our objective is to have a running JIT for the new aarch64 architecture (ARM 64bits). This task includes not only a new backend for the JIT compiler but also adding support for external libraries, dependencies and the build process. > This means having a working VM with comparable features as the one existing in Intel X64. We are targeting all the major operating systems running in this platform (Linux, OSX, Windows). > Each of them present different restrictions and conditions. > > This is the current status: > > - We implemented a full backend for the JIT compiler targeting aarch64. > - All the image side was adapted to run on it, tested on Ubuntu ARM 64 bits. > - We added support for: Iceberg (Libgit) / Athens (Cairo) / SDL / GTK > - We implemented a LibFFI-based FFI backend as the default one for Pharo 9 in aarch64 (next to come in all platforms). > This opens the door to ease port the features to other platforms and OSes. > > ## Following Steps and Open Betas: Linux Open Build System (OBS), Windows ARM64 and Apple Silicon > > Linux Systems: In the following days, we will also support Raspbian (Debian) and Manjaro on ARM64. For doing so, we are pushing the last details in having a single Linux build system through OBS. So, if you want to start doing beta-testing of these versions please contact us. A public beta will be open in around two weeks. > > Windows Systems: We have extended the build process to fully support Microsoft Visual Studio compilers and more flexibility to select the targets, also we are building it to run in Windows ARM. To correctly run the VM in Windows it is needed to build all dependencies for aarch64. In the following weeks, we expect to have a working Non-JIT version and a JIT version. The remaining points to have a JIT version are related with the build process as the API of the operating system has not changed from X64 to aarch64. > > OSX Systems: Our third target is to have a working version for the newest Apple silicon. We are acquiring the corresponding hardware to test and to address the differences in the API exposed to JIT applications. As it is the case of the Windows VM, there is not need to change the machine code generation backend; but to compile external libraries, and particularities of the new OS version. > > Thanks for your support, and again, if you like to start beta testing the VM please contact us. In the meantime, we will continue giving you news about the current state and where are we going. > > The consortium would like to particularly thank Schmidt Buro and Lifeware for their contracts. > > Regards, > > Pablo in behalf of the Pharo Consortium Engineers > -------------------------------------------- > StÃ©phane Ducasse > http://stephane.ducasse.free.fr / http://www.pharo.org > 03 59 35 87 52 > Assistant: Aurore Dalle > FAX 03 59 57 78 50 > TEL 03 59 35 86 16 > S. Ducasse - Inria > 40, avenue Halley, > Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza > Villeneuve d'Ascq 59650 > France > -- Sven Van Caekenberghe Proudly supporting Pharo http://pharo.org http://association.pharo.org http://consortium.pharo.org

Dec. 13, 2020

Call for Beta-testers Pharo ARM64 JIT

by StÃ©phane Ducasse

Dear happy Pharoers and others, Over the last months we have been working on the implementation of a MIT-licensed ARMv8 Just-In-Time compiler for Pharo VM. We are very happy with the advance on this subject, as we have not only implemented a new backend but we have added more than 2500 tests to the JIT, the primitives, code generation, plugins and the VM in general. In the process we fixed many problems. It shows that following the roadmap that was decided during General assembly of PharoDays, we have been investing in the Pharo VM and that our efforts are greatly paying off. Also, we are generating a lot of documentation and improving the process to really democratize the development of the VM. So Pharo is a better shape than ever on such matter and this opens a lot of possibility for the future. ## Call for Beta-Testers We would like to announce that a first version of our JIT backend is available for beta-testing for ARM Linux machines using Ubuntu. We are now entering into a beta testing stage of the VM and the image in Ubuntu ARM 64. We would like to invite you to our beta testing phase for the VM. If you're interested in participating, please contact pablo.tesone(a)inria.fr. The following sections give more details of the current status, and the following steps including Apple Silicon, Windows ARM64 and Linux Open Build System support. ## Current Status Our objective is to have a running JIT for the new aarch64 architecture (ARM 64bits). This task includes not only a new backend for the JIT compiler but also adding support for external libraries, dependencies and the build process. This means having a working VM with comparable features as the one existing in Intel X64. We are targeting all the major operating systems running in this platform (Linux, OSX, Windows). Each of them present different restrictions and conditions. This is the current status: - We implemented a full backend for the JIT compiler targeting aarch64. - All the image side was adapted to run on it, tested on Ubuntu ARM 64 bits. - We added support for: Iceberg (Libgit) / Athens (Cairo) / SDL / GTK - We implemented a LibFFI-based FFI backend as the default one for Pharo 9 in aarch64 (next to come in all platforms). This opens the door to ease port the features to other platforms and OSes. ## Following Steps and Open Betas: Linux Open Build System (OBS), Windows ARM64 and Apple Silicon Linux Systems: In the following days, we will also support Raspbian (Debian) and Manjaro on ARM64. For doing so, we are pushing the last details in having a single Linux build system through OBS. So, if you want to start doing beta-testing of these versions please contact us. A public beta will be open in around two weeks. Windows Systems: We have extended the build process to fully support Microsoft Visual Studio compilers and more flexibility to select the targets, also we are building it to run in Windows ARM. To correctly run the VM in Windows it is needed to build all dependencies for aarch64. In the following weeks, we expect to have a working Non-JIT version and a JIT version. The remaining points to have a JIT version are related with the build process as the API of the operating system has not changed from X64 to aarch64. OSX Systems: Our third target is to have a working version for the newest Apple silicon. We are acquiring the corresponding hardware to test and to address the differences in the API exposed to JIT applications. As it is the case of the Windows VM, there is not need to change the machine code generation backend; but to compile external libraries, and particularities of the new OS version. Thanks for your support, and again, if you like to start beta testing the VM please contact us. In the meantime, we will continue giving you news about the current state and where are we going. The consortium would like to particularly thank Schmidt Buro and Lifeware for their contracts. Regards, Pablo in behalf of the Pharo Consortium Engineers -------------------------------------------- StÃ©phane Ducasse http://stephane.ducasse.free.fr / http://www.pharo.org 03 59 35 87 52 Assistant: Aurore Dalle FAX 03 59 57 78 50 TEL 03 59 35 86 16 S. Ducasse - Inria 40, avenue Halley, Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza Villeneuve d'Ascq 59650 France

Dec. 12, 2020

This week (50/2020) on the Issue Tracker

by Marcus Denker

Another week with ~50 merged pull requests. Class Definitions ================== Mostly stabilizing the last changes... - Class>>#asRingDefinition should not send #definition but #definitionString #8024 https://github.com/pharo-project/pharo/pull/8024 - ReSearchStringSourceAnchor>>#interval should not use deprecated #definition #8022 https://github.com/pharo-project/pharo/pull/8022 - 7980-fix-checkClassRebuild #7982 https://github.com/pharo-project/pharo/pull/7982 - Move old definition printing to a the legacy printer #7894 https://github.com/pharo-project/pharo/pull/7894 Halt Cleanup ============= Finished: we now have a release test. There can never be a #halt left without the test failing. - 7925-halt-left-in-FFIFunctionParsersetOn #7932 https://github.com/pharo-project/pharo/pull/7932 - 7928-halt-left-in-FBDDecompilerpushFullClosurenumCopiedreceiverOnStackignoreOuterContext #7970 https://github.com/pharo-project/pharo/pull/7970 - 7975-ReleaseTesttestMethodsContainNoHalt #7977 https://github.com/pharo-project/pharo/pull/7977 - "Browse Breakpoints" should not show implementation methods #7969 https://github.com/pharo-project/pharo/pull/7969 Fixes ===== - Lazily file open in Zip archive #7999 https://github.com/pharo-project/pharo/pull/7999 - 8037-Scrolling-messages-leads-to-red-square-of-death #8039 https://github.com/pharo-project/pharo/pull/8039 - Fixed #8014. Renamed Random >> nextInt: and nextIntBetween:and: to nextInteger: and nextIntegerBetween:and: #8021 https://github.com/pharo-project/pharo/pull/8021 - Fix win32 library name for freetype #7778 https://github.com/pharo-project/pharo/pull/7778 - 7966-Temporary-Variables-Cannot-be-used-in-loops-in-a-playground #7983 https://github.com/pharo-project/pharo/pull/7983 - Only concrete Font descriptions should be installable #7986 https://github.com/pharo-project/pharo/pull/7986 - Fixed #7612. The bug that happened when an IntegerArray was added to a FloatArray #7622 https://github.com/pharo-project/pharo/pull/7622 - Fixed #7937. Implemented Random>>nextBetween:and:, nextIntBetween:and:, and wrote tests for them #7938 https://github.com/pharo-project/pharo/pull/7938 - 7956-Completion-broken-in-Transcript #7958 https://github.com/pharo-project/pharo/pull/7958 - fixing-FFIBackend-initialization #7973 https://github.com/pharo-project/pharo/pull/7973 - Fixing mem leak after debugger proceeding #7992 https://github.com/pharo-project/pharo/pull/7992 - 7953 huge debugger st pharo application memory leak #7976 https://github.com/pharo-project/pharo/pull/7976 - 8005-ClassHierarchyPrinter-glitches #8012 https://github.com/pharo-project/pharo/pull/8012 - 8001-Improving-ClassHierarchyPrinter #8003 https://github.com/pharo-project/pharo/pull/8003 - tagsForClasses #8008 https://github.com/pharo-project/pharo/pull/8008 - add Trait>>#isUsed. #7981 https://github.com/pharo-project/pharo/pull/7981 Refactoring ============ Work has begun to check (and fix) refactorings. More to come. - Review refactorings #7965 https://github.com/pharo-project/pharo/pull/7965 - Fix rename refactoring issue - 7947 #7978 https://github.com/pharo-project/pharo/pull/7978 AST Improvements / Cleanups ============================ The visitor now calls #visitGlobalVariableNode:, visitClassVariableNode:, if you inherit (or use the trait) the change is backward compatible (it makes sure to call the same methods as before). - AST-add-more-Variable-visit-methods #7929 https://github.com/pharo-project/pharo/pull/7929 - TRBProgramNodeVisitor-methods-missing #7962 https://github.com/pharo-project/pharo/pull/7962 - AST-Cleanup-visitUnreachableStatement #7951 https://github.com/pharo-project/pharo/pull/7951 - CoTypeInferencer should inherit from RBProgramNodeVisitor #8040 https://github.com/pharo-project/pharo/pull/8040 - 7993-Completion-broken-while-editing #7998 https://github.com/pharo-project/pharo/pull/7998 Cleanups and improvements Code Critique ====================== - ReSendsUnknownMessageToGlobalRule laments wrongly on class variables #8031 https://github.com/pharo-project/pharo/pull/8031 - Mark abstract test classes in Renraku-Tests #8029 https://github.com/pharo-project/pharo/pull/8029 - Cleanup ReAbstractRule #8057 https://github.com/pharo-project/pharo/pull/8057 - Clean selector casing in Renraku #8063 https://github.com/pharo-project/pharo/pull/8063 - Add script pragmas to CriticBrowser #8035 https://github.com/pharo-project/pharo/pull/8035 - Simplify-ReUnaryAccessingMethodWithoutReturnRule #7839 https://github.com/pharo-project/pharo/pull/7839 Dead Code ========= - Gofer-UI package should be removed in Pharo 9 #8027 https://github.com/pharo-project/pharo/pull/8027 - Deprecate leadingChar and old encoders. #7892 https://github.com/pharo-project/pharo/pull/7892 - remove-unused-charScannerPrimitive #7884 https://github.com/pharo-project/pharo/pull/7884 - Cleanup-EncoderForV3PlusClosures #7972 https://github.com/pharo-project/pharo/pull/7972 - Remove unused lastKeyboardFocus ivare from OSSDL2BackendWindow #7946 https://github.com/pharo-project/pharo/pull/7946 Other Cleanups ============== - ReSourceAnchor typo in class comment #8066 https://github.com/pharo-project/pharo/pull/8066 - Tag uncategorized classes in package Morphic-Widgets-Tabs #8015 https://github.com/pharo-project/pharo/pull/8015 - EpApplyPreviewerTest calls deprecated method #8007 https://github.com/pharo-project/pharo/pull/8007 - HDTestCoverage and HDCoverageReport use obsolete actualClass #7991 https://github.com/pharo-project/pharo/pull/7991 - fixes #7924: Enhance CodeImporter with better comment #7988 https://github.com/pharo-project/pharo/pull/7988

Dec. 11, 2020

Re: Pharo 8 Image blows up after restart

by Guillermo Polito

Cool :) Glad to help > El 9 dic 2020, a las 10:46, Sabine Manaa <manaa.sabine(a)gmail.com> escribiÃ³: > > Hi Eliot, hi Guille, > > you saved my day! > > starting from command line and killing with SIGUSR1 showed the stack below. > > Starting the image without mongoservice running avoids the blowup. > > Then, saving the image, starting mongoservice again and then I can proceed > using the image. > > I don't know yet why I get the > MongoWireProtocolError(MongoNativeError)>messageText but I have a point > where I can start seaching. > > Thanks a lot > Sabine > > > > > SIGUSR1 Wed Dec 9 09:51:45 2020 > > > VM: 202002121007 https://github.com/pharo-project/opensmalltalk-vm.git > Date: Wed Feb 12 11:07:12 2020 CommitHash: 2bd9e39 > Plugins: 202002121007 https://github.com/pharo-project/opensmalltalk-vm.git > > C stack backtrace & registers: > rax 0x00000001107d28f0 rbx 0x0000000000000003 rcx 0x0000000000000000 rdx > 0x0000000000000008 > rdi 0x00000003351a4690 rsi 0x00000003351a4690 rbp 0x00007ffeea61f050 rsp > 0x00007ffeea61f020 > r8 0x00ffffffffffffff r9 0x0000000000000001 r10 0x00000003351a4698 r11 > 0x000000022b0c8fc8 > r12 0x00000003351a45d8 r13 0x0000000000000001 r14 0x0000000000000000 r15 > 0x0000000000000006 > rip 0x00000001055f9862 > 0 Pharo 0x00000001055f9862 > scavengeReferentsOf + 277 > 1 Pharo 0x00000001056392da reportStackState > + 952 > 2 Pharo 0x00000001056394f8 sigusr1 + 182 > 3 libsystem_platform.dylib 0x00007fff725995fd _sigtramp + 29 > 4 ??? 0x00000000c0000000 0x0 + 3221225472 > 5 Pharo 0x00000001055d5eea doScavenge + 542 > 6 Pharo 0x00000001055de05e > scavengingGCTenuringIf + 333 > 7 Pharo 0x00000001055c163a > checkForEventsMayContextSwitch + 111 > 8 Pharo 0x00000001055c5815 ceStackOverflow + > 110 > 9 ??? 0x0000000109cca53b 0x0 + 4459373883 > 10 Pharo 0x00000001055adb0a interpret + 632 > 11 Pharo 0x000000010563aa62 > -[sqSqueakMainApplication runSqueak] + 393 > 12 Foundation 0x00007fff3aac429b > __NSFirePerformWithOrder + 360 > 13 CoreFoundation 0x00007fff38330335 > __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 23 > 14 CoreFoundation 0x00007fff38330267 > __CFRunLoopDoObservers + 457 > 15 CoreFoundation 0x00007fff3832f805 __CFRunLoopRun + > 874 > 16 CoreFoundation 0x00007fff3832ee3e > CFRunLoopRunSpecific + 462 > 17 HIToolbox 0x00007fff36f5babd > RunCurrentEventLoopInMode + 292 > 18 HIToolbox 0x00007fff36f5b6f4 > ReceiveNextEventCommon + 359 > 19 HIToolbox 0x00007fff36f5b579 > _BlockUntilNextEventMatchingListInModeWithFilter + 64 > 20 AppKit 0x00007fff355a1039 _DPSNextEvent + > 883 > 21 AppKit 0x00007fff3559f880 > -[NSApplication(NSEvent) > _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 1352 > 22 AppKit 0x00007fff3559158e -[NSApplication > run] + 658 > 23 AppKit 0x00007fff35563396 NSApplicationMain > + 777 > 24 libdyld.dylib 0x00007fff723a0cc9 start + 1 > 25 ??? 0x0000000000000002 0x0 + 2 > > > All Smalltalk process stacks (active first): > Process 0x120172de8 priority 20 > 0x7ffeea630130 M MongoWireProtocolError(MongoNativeError)>messageText > 0x120173f58: a(n) MongoWireProtocolError > 0x7ffeea63d980 M MongoWireProtocolError>errorMessage 0x120173f58: a(n) > MongoWireProtocolError > 0x7ffeea63d9b0 M MongoWireProtocolError(MongoNativeError)>messageText > 0x120173f58: a(n) MongoWireProtocolError > 0x7ffeea63d9e0 M MongoWireProtocolError>errorMessage 0x120173f58: a(n) > MongoWireProtocolError > 0x7ffeea63da10 M MongoWireProtocolError(MongoNativeError)>messageText > 0x120173f58: a(n) MongoWireProtocolError > 0x7ffeea63da40 M MongoWireProtocolError>errorMessage 0x120173f58: a(n) > MongoWireProtocolError > 0x7ffeea63da70 M MongoWireProtocolError(MongoNativeError)>messageText > 0x120173f58: a(n) MongoWireProtocolError > 0x7ffeea63daa0 M MongoWireProtocolError>errorMessage 0x120173f58: a(n) > MongoWireProtocolError > 0x7ffeea63dad0 M MongoWireProtocolError(MongoNativeError)>messageText > 0x120173f58: a(n) MongoWireProtocolError > 0x7ffeea63db00 M MongoWireProtocolError>errorMessage 0x120173f58: a(n) > MongoWireProtocolError > 0x7ffeea63db30 M MongoWireProtocolError(MongoNativeError)>messageText > 0x120173f58: a(n) MongoWireProtocolError > 0x7ffeea63db60 M MongoWireProtocolError>errorMessage 0x120173f58: a(n) > MongoWireProtocolError > 0x7ffeea63db90 M MongoWireProtocolError(MongoNativeError)>messageText > 0x120173f58: a(n) MongoWireProtocolError > 0x7ffeea63dbc0 M MongoWireProtocolError>errorMessage 0x120173f58: a(n) > MongoWireProtocolError > 0x7ffeea63dbf0 M MongoWireProtocolError(MongoNativeError)>messageText > 0x120173f58: a(n) MongoWireProtocolError > 0x7ffeea63dc20 M MongoWireProtocolError>errorMessage 0x120173f58: a(n) > MongoWireProtocolError > 0x7ffeea63dc50 M MongoWireProtocolError(MongoNativeError)>messageText > 0x120173f58: a(n) MongoWireProtocolError > 0x7ffeea63dc80 M MongoWireProtocolError>errorMessage 0x120173f58: a(n) > MongoWireProtocolError > 0x7ffeea63dcb0 M MongoWireProtocolError(MongoNativeError)>messageText > 0x120173f58: a(n) MongoWireProtocolError > 0x7ffeea63dce0 M MongoWireProtocolError>errorMessage 0x120173f58: a(n) > MongoWireProtocolError > 0x7ffeea63dd10 M MongoWireProtocolError(MongoNativeError)>messageText > 0x120173f58: a(n) MongoWireProtocolError > > (repeat 100.000 times).... > 0x1196a9fa8 s MongoWireProtocolError(MongoNativeError)>messageText > 0x1196aa060 s MongoWireProtocolError>errorMessage > 0x1196aa118 s MongoWireProtocolError(MongoNativeError)>messageText > 0x1196aa1d0 s MongoWireProtocolError>errorMessage > 0x1196aa288 s MongoWireProtocolError(MongoNativeError)>messageText > 0x1196aa340 s [] in MongoWireProtocolError(Exception)>description > 0x1196aa3f8 s String class(SequenceableCollection > class)>new:streamContents: > 0x1196aa4b0 s String class(SequenceableCollection > class)>streamContents: > 0x1196aa568 s MongoWireProtocolError(Exception)>description > 0x1196aa620 s MongoWireProtocolError(Exception)>debug > 0x1196aa6d8 s MorphicUIManager>unhandledErrorDefaultAction: > 0x1196aa790 s UnhandledError>defaultAction > 0x1196aa848 s UndefinedObject>handleSignal: > 0x1196aa900 s Context>handleSignal: > 0x1196aa9b8 s UnhandledError(Exception)>signal > 0x1196aaa70 s UnhandledError class>signalForException: > 0x1196aab28 s MongoWireProtocolError(Error)>defaultAction > 0x1196aabe0 s UndefinedObject>handleSignal: > 0x1196aac98 s Context>handleSignal: > 0x119b91af8 s MongoWireProtocolError(Exception)>signal > 0x119b91d20 s MongoWireProtocolError(Exception)>signal: > 0x119b91f48 s MongoWireProtocolError class(Exception class)>signal: > 0x119b91988 s MongoCursor>execute > 0x119b91c68 s Mongo>queryOne: > 0x119b91e90 s Mongo>command:database:flags: > 0x119b920b8 s Mongo>command:database: > 0x119b92228 s [] in > SCRAMSHA1AuthMechanism>authenticateUsername:password:forcedDatabase: > 0x119b91a40 s BlockClosure>on:do: > 0x120221980 s > SCRAMSHA1AuthMechanism>authenticateUsername:password:forcedDatabase: > 0x120221c48 s > SCRAMSHA1AuthMechanism(MongoAuthMechanism)>authenticateUsername:password:database: > 0x120222010 s Mongo>authenticateUsername:password:database: > 0x120222300 s RKARepositoryManager class>authenticateAdminRepository > 0x120223688 s RKARepositoryManager class>databaseNames > 0x120223988 s RKARepositoryManager class>customerDatabaseNames > 0x120223be8 s RKAMailSender class>sendReminderMails > 0x120223d88 s [] in RKAScheduler class>newReminderMailsScheduler > 0x12043fac0 s [] in ScheduledTask>run > 0x120442d98 s BlockClosure>ensure: > 0x120445d90 s [] in ScheduledTask>run > 0x120448eb0 s [] in BlockClosure>newProcess > > processes at priority 10 > Process 0x1191f2220 priority 10 > 0x1201735e8 s ProcessorScheduler class>idleProcess > 0x1201879e8 s [] in ProcessorScheduler class>startUp > 0x1191f7d80 s [] in BlockClosure>newProcess > > Process 0x119f75ed0 priority 10 > 0x12eaa4228 s [] in BlockClosure>newProcess > > Process 0x181024e98 priority 10 > 0x1810253c8 s [] in BlockClosure>newProcess > > Process 0x1d5a8e568 priority 10 > 0x1d5a8f020 s [] in BlockClosure>newProcess > > Process 0x17eaa3c78 priority 10 > 0x1f23c8698 s [] in BlockClosure>newProcess > > Process 0x2111a5f20 priority 10 > 0x2111a6320 s [] in BlockClosure>newProcess > > Process 0x2590f8cd8 priority 10 > 0x2590faa98 s [] in BlockClosure>newProcess > > Process 0x279aadfa0 priority 10 > 0x27ac91450 s [] in BlockClosure>newProcess > > Process 0x2b6261ee0 priority 10 > 0x2b62624f0 s [] in BlockClosure>newProcess > > Process 0x2de054360 priority 10 > 0x2de0549b0 s [] in BlockClosure>newProcess > > Process 0x29eb28580 priority 10 > 0x2fcdffb28 s [] in BlockClosure>newProcess > > Process 0x31b7dfa68 priority 10 > 0x31b7e05d0 s [] in BlockClosure>newProcess > > suspended processes > Process 0x1191f2cb0 priority 50 > 0x1191f8af0 s WeakArray class>finalizationProcess > 0x120173ea0 s [] in WeakArray class>restartFinalizationProcess > 0x119ed8b78 s [] in BlockClosure>newProcess > > Process 0x10cd52ed0 priority 80 > 0x109f28000 s DelayMicrosecondTicker>waitForUserSignalled:orExpired: > 0x10da04408 s [] in > DelaySemaphoreScheduler(DelayBasicScheduler)>runBackendLoopAtTimingPriority > 0x10da04620 s BlockClosure>ensure: > 0x10ce7e868 s > DelaySemaphoreScheduler(DelayBasicScheduler)>runBackendLoopAtTimingPriority > 0x10da04350 s [] in > DelaySemaphoreScheduler(DelayBasicScheduler)>startTimerEventLoopPriority: > 0x10ce7e940 s [] in BlockClosure>newProcess > > Process 0x1121775c0 priority 31 > 0x118db5a88 s AtomicSharedQueue>waitForNewItems > 0x118e51048 s AtomicSharedQueue>next > 0x119196820 s [] in ClyDataSourceUpdateScheduler>processQueue > 0x112187878 s BlockClosure>repeat > 0x11217e940 s ClyDataSourceUpdateScheduler>processQueue > 0x1121877c0 s [] in ClyDataSourceUpdateScheduler>ensureRunning > 0x11217ea18 s [] in BlockClosure>newProcess > > Process 0x1191f21d0 priority 60 > 0x1191f7cc8 s SmalltalkImage>lowSpaceWatcher > 0x120173d30 s [] in SmalltalkImage>installLowSpaceWatcher > 0x119ed8100 s [] in BlockClosure>newProcess > > Process 0x1191f2998 priority 40 > 0x326d25100 s [] in DelayWaitTimeout>wait > 0x327434bf0 s BlockClosure>ensure: > 0x326d258b8 s DelayWaitTimeout>wait > 0x327435268 s Semaphore>waitTimeoutMSecs: > 0x3274355e0 s [] in UnixOSProcessAccessor>grimReaperProcess > 0x120204400 s BlockClosure>repeat > 0x119ed8cb0 s [] in UnixOSProcessAccessor>grimReaperProcess > 0x119ed8d98 s [] in BlockClosure>newProcess > > Process 0x1191f3120 priority 60 > 0x1408b30d0 s InputEventFetcher>waitForInput > 0x120174528 s InputEventFetcher>eventLoop > 0x12018b9e8 s [] in InputEventFetcher>installEventLoop > 0x119ed8a50 s [] in BlockClosure>newProcess > > Process 0x1191f3030 priority 70 > 0x1191f9070 s [] in DelayWaitTimeout>wait > 0x120173998 s BlockClosure>ensure: > 0x119e57648 s DelayWaitTimeout>wait > 0x120173a50 s Semaphore>waitTimeoutMSecs: > 0x12018adb0 s Socket>waitForConnectionFor:ifTimedOut: > 0x119ed84b8 s Socket>waitForAcceptFor:ifTimedOut: > 0x119ed8590 s Socket>waitForAcceptFor: > 0x120173b08 s > ZnManagingMultiThreadedServer(ZnMultiThreadedServer)>serveConnectionsOn: > 0x12018ae68 s [] in > ZnManagingMultiThreadedServer(ZnMultiThreadedServer)>listenLoop > 0x12019a808 s BlockClosure>repeat > 0x119ed8668 s [] in > ZnManagingMultiThreadedServer(ZnMultiThreadedServer)>listenLoop > 0x120173bc0 s BlockClosure>ifCurtailed: > 0x119ed8760 s > ZnManagingMultiThreadedServer(ZnMultiThreadedServer)>listenLoop > 0x120173c78 s [] in > ZnManagingMultiThreadedServer(ZnSingleThreadedServer)>start > 0x12018af20 s BlockClosure>repeat > 0x119ed8838 s [] in > ZnManagingMultiThreadedServer(ZnSingleThreadedServer)>start > 0x119ed8910 s [] in BlockClosure>newProcess > > Process 0x1191f27c8 priority 70 > 0x109f280b8 s [] in Delay>wait > 0x109f2cbc8 s BlockClosure>ifCurtailed: > 0x109f2cf40 s Delay>wait > 0x109f2d260 s [] in OSSVMProcess>initializeChildWatcher > 0x12021cd08 s BlockClosure>repeat > 0x119ed82b8 s [] in OSSVMProcess>initializeChildWatcher > 0x119ed8398 s [] in BlockClosure>newProcess > > Most recent primitives > **StackOverflow** > **StackOverflow** > **StackOverflow** > **StackOverflow** > **StackOverflow** > **StackOverflow** > **StackOverflow** > **StackOverflow** > **StackOverflow** > **StackOverflow** > **StackOverflow** > **StackOverflow** > **StackOverflow** > **StackOverflow** > **StackOverflow** > **StackOverflow** > **StackOverflow** > **StackOverflow** > **StackOverflow** > **StackOverflow** > stack page bytes 4096 available headroom 1480 minimum unused headroom 848 > > (SIGUSR1) > bash: line 1: 29529 Terminated: 15 > "/Users/sabine/Documents/Pharo/vms/80-x64/Pharo.app/Contents/MacOS/Pharo" > "/Users/sabine/Documents/Pharo/images/Pharo 8.0 - 64bit (15)/Pharo 8.0 - > 64bit (15).image" > Sabines-MBP:~ sabine$ > . > > > > > > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Dec. 9, 2020

Re: Pharo 8 Image blows up after restart

by Sabine Manaa

Hi Eliot, hi Guille, you saved my day! starting from command line and killing with SIGUSR1 showed the stack below. Starting the image without mongoservice running avoids the blowup. Then, saving the image, starting mongoservice again and then I can proceed using the image. I don't know yet why I get the MongoWireProtocolError(MongoNativeError)>messageText but I have a point where I can start seaching. Thanks a lot Sabine SIGUSR1 Wed Dec 9 09:51:45 2020 VM: 202002121007 https://github.com/pharo-project/opensmalltalk-vm.git Date: Wed Feb 12 11:07:12 2020 CommitHash: 2bd9e39 Plugins: 202002121007 https://github.com/pharo-project/opensmalltalk-vm.git C stack backtrace & registers: rax 0x00000001107d28f0 rbx 0x0000000000000003 rcx 0x0000000000000000 rdx 0x0000000000000008 rdi 0x00000003351a4690 rsi 0x00000003351a4690 rbp 0x00007ffeea61f050 rsp 0x00007ffeea61f020 r8 0x00ffffffffffffff r9 0x0000000000000001 r10 0x00000003351a4698 r11 0x000000022b0c8fc8 r12 0x00000003351a45d8 r13 0x0000000000000001 r14 0x0000000000000000 r15 0x0000000000000006 rip 0x00000001055f9862 0 Pharo 0x00000001055f9862 scavengeReferentsOf + 277 1 Pharo 0x00000001056392da reportStackState + 952 2 Pharo 0x00000001056394f8 sigusr1 + 182 3 libsystem_platform.dylib 0x00007fff725995fd _sigtramp + 29 4 ??? 0x00000000c0000000 0x0 + 3221225472 5 Pharo 0x00000001055d5eea doScavenge + 542 6 Pharo 0x00000001055de05e scavengingGCTenuringIf + 333 7 Pharo 0x00000001055c163a checkForEventsMayContextSwitch + 111 8 Pharo 0x00000001055c5815 ceStackOverflow + 110 9 ??? 0x0000000109cca53b 0x0 + 4459373883 10 Pharo 0x00000001055adb0a interpret + 632 11 Pharo 0x000000010563aa62 -[sqSqueakMainApplication runSqueak] + 393 12 Foundation 0x00007fff3aac429b __NSFirePerformWithOrder + 360 13 CoreFoundation 0x00007fff38330335 __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 23 14 CoreFoundation 0x00007fff38330267 __CFRunLoopDoObservers + 457 15 CoreFoundation 0x00007fff3832f805 __CFRunLoopRun + 874 16 CoreFoundation 0x00007fff3832ee3e CFRunLoopRunSpecific + 462 17 HIToolbox 0x00007fff36f5babd RunCurrentEventLoopInMode + 292 18 HIToolbox 0x00007fff36f5b6f4 ReceiveNextEventCommon + 359 19 HIToolbox 0x00007fff36f5b579 _BlockUntilNextEventMatchingListInModeWithFilter + 64 20 AppKit 0x00007fff355a1039 _DPSNextEvent + 883 21 AppKit 0x00007fff3559f880 -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 1352 22 AppKit 0x00007fff3559158e -[NSApplication run] + 658 23 AppKit 0x00007fff35563396 NSApplicationMain + 777 24 libdyld.dylib 0x00007fff723a0cc9 start + 1 25 ??? 0x0000000000000002 0x0 + 2 All Smalltalk process stacks (active first): Process 0x120172de8 priority 20 0x7ffeea630130 M MongoWireProtocolError(MongoNativeError)>messageText 0x120173f58: a(n) MongoWireProtocolError 0x7ffeea63d980 M MongoWireProtocolError>errorMessage 0x120173f58: a(n) MongoWireProtocolError 0x7ffeea63d9b0 M MongoWireProtocolError(MongoNativeError)>messageText 0x120173f58: a(n) MongoWireProtocolError 0x7ffeea63d9e0 M MongoWireProtocolError>errorMessage 0x120173f58: a(n) MongoWireProtocolError 0x7ffeea63da10 M MongoWireProtocolError(MongoNativeError)>messageText 0x120173f58: a(n) MongoWireProtocolError 0x7ffeea63da40 M MongoWireProtocolError>errorMessage 0x120173f58: a(n) MongoWireProtocolError 0x7ffeea63da70 M MongoWireProtocolError(MongoNativeError)>messageText 0x120173f58: a(n) MongoWireProtocolError 0x7ffeea63daa0 M MongoWireProtocolError>errorMessage 0x120173f58: a(n) MongoWireProtocolError 0x7ffeea63dad0 M MongoWireProtocolError(MongoNativeError)>messageText 0x120173f58: a(n) MongoWireProtocolError 0x7ffeea63db00 M MongoWireProtocolError>errorMessage 0x120173f58: a(n) MongoWireProtocolError 0x7ffeea63db30 M MongoWireProtocolError(MongoNativeError)>messageText 0x120173f58: a(n) MongoWireProtocolError 0x7ffeea63db60 M MongoWireProtocolError>errorMessage 0x120173f58: a(n) MongoWireProtocolError 0x7ffeea63db90 M MongoWireProtocolError(MongoNativeError)>messageText 0x120173f58: a(n) MongoWireProtocolError 0x7ffeea63dbc0 M MongoWireProtocolError>errorMessage 0x120173f58: a(n) MongoWireProtocolError 0x7ffeea63dbf0 M MongoWireProtocolError(MongoNativeError)>messageText 0x120173f58: a(n) MongoWireProtocolError 0x7ffeea63dc20 M MongoWireProtocolError>errorMessage 0x120173f58: a(n) MongoWireProtocolError 0x7ffeea63dc50 M MongoWireProtocolError(MongoNativeError)>messageText 0x120173f58: a(n) MongoWireProtocolError 0x7ffeea63dc80 M MongoWireProtocolError>errorMessage 0x120173f58: a(n) MongoWireProtocolError 0x7ffeea63dcb0 M MongoWireProtocolError(MongoNativeError)>messageText 0x120173f58: a(n) MongoWireProtocolError 0x7ffeea63dce0 M MongoWireProtocolError>errorMessage 0x120173f58: a(n) MongoWireProtocolError 0x7ffeea63dd10 M MongoWireProtocolError(MongoNativeError)>messageText 0x120173f58: a(n) MongoWireProtocolError (repeat 100.000 times).... 0x1196a9fa8 s MongoWireProtocolError(MongoNativeError)>messageText 0x1196aa060 s MongoWireProtocolError>errorMessage 0x1196aa118 s MongoWireProtocolError(MongoNativeError)>messageText 0x1196aa1d0 s MongoWireProtocolError>errorMessage 0x1196aa288 s MongoWireProtocolError(MongoNativeError)>messageText 0x1196aa340 s [] in MongoWireProtocolError(Exception)>description 0x1196aa3f8 s String class(SequenceableCollection class)>new:streamContents: 0x1196aa4b0 s String class(SequenceableCollection class)>streamContents: 0x1196aa568 s MongoWireProtocolError(Exception)>description 0x1196aa620 s MongoWireProtocolError(Exception)>debug 0x1196aa6d8 s MorphicUIManager>unhandledErrorDefaultAction: 0x1196aa790 s UnhandledError>defaultAction 0x1196aa848 s UndefinedObject>handleSignal: 0x1196aa900 s Context>handleSignal: 0x1196aa9b8 s UnhandledError(Exception)>signal 0x1196aaa70 s UnhandledError class>signalForException: 0x1196aab28 s MongoWireProtocolError(Error)>defaultAction 0x1196aabe0 s UndefinedObject>handleSignal: 0x1196aac98 s Context>handleSignal: 0x119b91af8 s MongoWireProtocolError(Exception)>signal 0x119b91d20 s MongoWireProtocolError(Exception)>signal: 0x119b91f48 s MongoWireProtocolError class(Exception class)>signal: 0x119b91988 s MongoCursor>execute 0x119b91c68 s Mongo>queryOne: 0x119b91e90 s Mongo>command:database:flags: 0x119b920b8 s Mongo>command:database: 0x119b92228 s [] in SCRAMSHA1AuthMechanism>authenticateUsername:password:forcedDatabase: 0x119b91a40 s BlockClosure>on:do: 0x120221980 s SCRAMSHA1AuthMechanism>authenticateUsername:password:forcedDatabase: 0x120221c48 s SCRAMSHA1AuthMechanism(MongoAuthMechanism)>authenticateUsername:password:database: 0x120222010 s Mongo>authenticateUsername:password:database: 0x120222300 s RKARepositoryManager class>authenticateAdminRepository 0x120223688 s RKARepositoryManager class>databaseNames 0x120223988 s RKARepositoryManager class>customerDatabaseNames 0x120223be8 s RKAMailSender class>sendReminderMails 0x120223d88 s [] in RKAScheduler class>newReminderMailsScheduler 0x12043fac0 s [] in ScheduledTask>run 0x120442d98 s BlockClosure>ensure: 0x120445d90 s [] in ScheduledTask>run 0x120448eb0 s [] in BlockClosure>newProcess processes at priority 10 Process 0x1191f2220 priority 10 0x1201735e8 s ProcessorScheduler class>idleProcess 0x1201879e8 s [] in ProcessorScheduler class>startUp 0x1191f7d80 s [] in BlockClosure>newProcess Process 0x119f75ed0 priority 10 0x12eaa4228 s [] in BlockClosure>newProcess Process 0x181024e98 priority 10 0x1810253c8 s [] in BlockClosure>newProcess Process 0x1d5a8e568 priority 10 0x1d5a8f020 s [] in BlockClosure>newProcess Process 0x17eaa3c78 priority 10 0x1f23c8698 s [] in BlockClosure>newProcess Process 0x2111a5f20 priority 10 0x2111a6320 s [] in BlockClosure>newProcess Process 0x2590f8cd8 priority 10 0x2590faa98 s [] in BlockClosure>newProcess Process 0x279aadfa0 priority 10 0x27ac91450 s [] in BlockClosure>newProcess Process 0x2b6261ee0 priority 10 0x2b62624f0 s [] in BlockClosure>newProcess Process 0x2de054360 priority 10 0x2de0549b0 s [] in BlockClosure>newProcess Process 0x29eb28580 priority 10 0x2fcdffb28 s [] in BlockClosure>newProcess Process 0x31b7dfa68 priority 10 0x31b7e05d0 s [] in BlockClosure>newProcess suspended processes Process 0x1191f2cb0 priority 50 0x1191f8af0 s WeakArray class>finalizationProcess 0x120173ea0 s [] in WeakArray class>restartFinalizationProcess 0x119ed8b78 s [] in BlockClosure>newProcess Process 0x10cd52ed0 priority 80 0x109f28000 s DelayMicrosecondTicker>waitForUserSignalled:orExpired: 0x10da04408 s [] in DelaySemaphoreScheduler(DelayBasicScheduler)>runBackendLoopAtTimingPriority 0x10da04620 s BlockClosure>ensure: 0x10ce7e868 s DelaySemaphoreScheduler(DelayBasicScheduler)>runBackendLoopAtTimingPriority 0x10da04350 s [] in DelaySemaphoreScheduler(DelayBasicScheduler)>startTimerEventLoopPriority: 0x10ce7e940 s [] in BlockClosure>newProcess Process 0x1121775c0 priority 31 0x118db5a88 s AtomicSharedQueue>waitForNewItems 0x118e51048 s AtomicSharedQueue>next 0x119196820 s [] in ClyDataSourceUpdateScheduler>processQueue 0x112187878 s BlockClosure>repeat 0x11217e940 s ClyDataSourceUpdateScheduler>processQueue 0x1121877c0 s [] in ClyDataSourceUpdateScheduler>ensureRunning 0x11217ea18 s [] in BlockClosure>newProcess Process 0x1191f21d0 priority 60 0x1191f7cc8 s SmalltalkImage>lowSpaceWatcher 0x120173d30 s [] in SmalltalkImage>installLowSpaceWatcher 0x119ed8100 s [] in BlockClosure>newProcess Process 0x1191f2998 priority 40 0x326d25100 s [] in DelayWaitTimeout>wait 0x327434bf0 s BlockClosure>ensure: 0x326d258b8 s DelayWaitTimeout>wait 0x327435268 s Semaphore>waitTimeoutMSecs: 0x3274355e0 s [] in UnixOSProcessAccessor>grimReaperProcess 0x120204400 s BlockClosure>repeat 0x119ed8cb0 s [] in UnixOSProcessAccessor>grimReaperProcess 0x119ed8d98 s [] in BlockClosure>newProcess Process 0x1191f3120 priority 60 0x1408b30d0 s InputEventFetcher>waitForInput 0x120174528 s InputEventFetcher>eventLoop 0x12018b9e8 s [] in InputEventFetcher>installEventLoop 0x119ed8a50 s [] in BlockClosure>newProcess Process 0x1191f3030 priority 70 0x1191f9070 s [] in DelayWaitTimeout>wait 0x120173998 s BlockClosure>ensure: 0x119e57648 s DelayWaitTimeout>wait 0x120173a50 s Semaphore>waitTimeoutMSecs: 0x12018adb0 s Socket>waitForConnectionFor:ifTimedOut: 0x119ed84b8 s Socket>waitForAcceptFor:ifTimedOut: 0x119ed8590 s Socket>waitForAcceptFor: 0x120173b08 s ZnManagingMultiThreadedServer(ZnMultiThreadedServer)>serveConnectionsOn: 0x12018ae68 s [] in ZnManagingMultiThreadedServer(ZnMultiThreadedServer)>listenLoop 0x12019a808 s BlockClosure>repeat 0x119ed8668 s [] in ZnManagingMultiThreadedServer(ZnMultiThreadedServer)>listenLoop 0x120173bc0 s BlockClosure>ifCurtailed: 0x119ed8760 s ZnManagingMultiThreadedServer(ZnMultiThreadedServer)>listenLoop 0x120173c78 s [] in ZnManagingMultiThreadedServer(ZnSingleThreadedServer)>start 0x12018af20 s BlockClosure>repeat 0x119ed8838 s [] in ZnManagingMultiThreadedServer(ZnSingleThreadedServer)>start 0x119ed8910 s [] in BlockClosure>newProcess Process 0x1191f27c8 priority 70 0x109f280b8 s [] in Delay>wait 0x109f2cbc8 s BlockClosure>ifCurtailed: 0x109f2cf40 s Delay>wait 0x109f2d260 s [] in OSSVMProcess>initializeChildWatcher 0x12021cd08 s BlockClosure>repeat 0x119ed82b8 s [] in OSSVMProcess>initializeChildWatcher 0x119ed8398 s [] in BlockClosure>newProcess Most recent primitives **StackOverflow** **StackOverflow** **StackOverflow** **StackOverflow** **StackOverflow** **StackOverflow** **StackOverflow** **StackOverflow** **StackOverflow** **StackOverflow** **StackOverflow** **StackOverflow** **StackOverflow** **StackOverflow** **StackOverflow** **StackOverflow** **StackOverflow** **StackOverflow** **StackOverflow** **StackOverflow** stack page bytes 4096 available headroom 1480 minimum unused headroom 848 (SIGUSR1) bash: line 1: 29529 Terminated: 15 "/Users/sabine/Documents/Pharo/vms/80-x64/Pharo.app/Contents/MacOS/Pharo" "/Users/sabine/Documents/Pharo/images/Pharo 8.0 - 64bit (15)/Pharo 8.0 - 64bit (15).image" Sabines-MBP:~ sabine$ . -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Dec. 9, 2020

Re: Pharo 8 Image blows up after restart

by Guillermo Polito

Another idea is that as soon as you detect the problem, you send the SIGUSR1 signal to the VM from another terminal. $ kill -SIGUSR1 thePID When the Pharo process receives the SIGUSR1 signal it will output a dump with - the C execution stack - the Pharo execution stacks Maybe for debugging this case you donât want to use the launcher, and you want to manually launch the VM from a terminal, so youâll have more control and see the output (maybe youâre already doing it, but just in case). G. > El 9 dic 2020, a las 6:35, Eliot Miranda <eliot.miranda(a)gmail.com> escribiÃ³: > > Hi Sabine, > >> On Dec 8, 2020, at 10:49 AM, Sabine Manaa <manaa.sabine(a)gmail.com> wrote: >> >> ï»¿Hi, >> >> I have the following problem: >> >> sometimes, after restarting my Pharo 8 image on mac, it is not responsive >> and it blows up the memory. >> >> I tried with commandline handler >> eval "self halt" >> and with >> Smalltalk addToStartUpList: >> >> but both is too late - the Image starts and blows up and is not responsive. >> >> I can not interrupt it and it grows to several GB memory (eg after 20 >> seconds 10 GigaByte! ) and I have to kill it. >> >> Anyone having an idea what I can do to find the reason for this? > > Run the system under a low level debugger (lldb, gdb). > Put a break point on the function sqAllocateMemorySegmentOfSizeAboveAllocatedSizeInto, which is called when the heap must grow to allocate new objects. > When the system hits the breakpoint for the second or third time call the function > printCallStack() > and be patient; it will print a lot of stack. > > There is also a command line argument to limit the maximum size of the heap. So an alternative might be to restrict the heap to a few megabytes above the image size and see if you get a crash.dmp file when the vm exits when the system runs out of memory. > > HTH > >> >> Sabine >> >> >> >> >> >> >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html <http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html>

Dec. 9, 2020

Re: Pharo 8 Image blows up after restart

by Eliot Miranda

Hi Sabine, > On Dec 8, 2020, at 10:49 AM, Sabine Manaa <manaa.sabine(a)gmail.com> wrote: > > ï»¿Hi, > > I have the following problem: > > sometimes, after restarting my Pharo 8 image on mac, it is not responsive > and it blows up the memory. > > I tried with commandline handler > eval "self halt" > and with > Smalltalk addToStartUpList: > > but both is too late - the Image starts and blows up and is not responsive. > > I can not interrupt it and it grows to several GB memory (eg after 20 > seconds 10 GigaByte! ) and I have to kill it. > > Anyone having an idea what I can do to find the reason for this? Run the system under a low level debugger (lldb, gdb). Put a break point on the function sqAllocateMemorySegmentOfSizeAboveAllocatedSizeInto, which is called when the heap must grow to allocate new objects. When the system hits the breakpoint for the second or third time call the function printCallStack() and be patient; it will print a lot of stack. There is also a command line argument to limit the maximum size of the heap. So an alternative might be to restrict the heap to a few megabytes above the image size and see if you get a crash.dmp file when the vm exits when the system runs out of memory. HTH > > Sabine > > > > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Dec. 9, 2020