http://permalink.gmane.org/gmane.comp.lang.scala hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.lang.scala/29453 <pre> For real? I've never seen anyone try to handle those explicitly, with the intent to "keep on trucking", because it indicates a bug or poorly configured JVM. The solution is the either fix the bug or configure the JVM properly. </pre> Nils Kilden-Pedersen 2013-05-24T16:52:22 http://permalink.gmane.org/gmane.comp.lang.scala/29452 <pre>very valuable guidelines. Thanks a lot! On Friday, 24 May 2013 11:44:45 UTC+1, fanf wrote: </pre> Fernando Racca 2013-05-24T16:38:55 http://permalink.gmane.org/gmane.comp.lang.scala/29451 <pre> Are you serious? If so, that's a security issue. You should have bounded request sizes -- above which requests are rejected before any parsing happens. If your requests require unbounded memory or processing then that's a problem at an even deeper level, but I digress... </pre> Bardur Arantsson 2013-05-24T16:34:28 http://permalink.gmane.org/gmane.comp.lang.scala/29450 <pre>Hi Lex This makes sense for a disposable app like a compiler instance or worker. But for a long running app you just can't let it crash because of user submitting a large number in his input. OOME and SOE are the ways to prevent hard crash. Do you suggest to halt the vm immediately like if it was a segfault instead of Error? Bypassing shutdown hooks as well because the vm is possibly broken? If the handler crashes with OOM then fine, we did our best. That is still better than crashing right away. Thanks for the info on Squeak. If i understand correctly it is mainly used for single-user systems so there is probably not much use for protection against malicious actions. Thanks, Aleh On Fri, 24 May 2013 19:00:23 +0300, Lex Spoon &lt;lex&lt; at &gt;lexspoon.org&gt; wrote: </pre> Aleh Aleshka 2013-05-24T16:30:16 http://permalink.gmane.org/gmane.comp.lang.scala/29449 <pre>Thanks! </pre> Ranie Jade Ramiso 2013-05-24T16:17:44 http://permalink.gmane.org/gmane.comp.lang.scala/29448 <pre>The GWT team went around and around about this for OutOfMemory errors in its compiler. My first instinct was not to bother handling OOM, but we tried a few ways anyway, and it's just insanely difficult. We ultimately gave up. Java is not designed for to support manual memory management. On the contrary, Java is expressly designed for you *not* to control memory usage. One of the problems is that your OOM handler cannot itself allocate any memory. This is because you don't know that the handler is running on the thread that is the memory hog. How do you write an OOM handler, though, without allocating memory? That's an unreasonable constraint for programming on the JVM. You can't add to a list. You can't allocate an array. You can't do string appends. You can't call into library routines. Another consequence of not knowing which thread will get the OOM is that it might be a thread you don't control. In such a case, the JVM is just going to exit and you can't do anything about it. As such, from a management </pre> Lex Spoon 2013-05-24T16:00:23 http://permalink.gmane.org/gmane.comp.lang.scala/29447 <pre> Hello, It's called automatic tupling and apparently it is an obscure feature: "Spec doesn't mention automatic tupling" https://issues.scala-lang.org/browse/SI-3583 Take care Oliver On Fri, May 24, 2013 at 11:06 AM, Ranie Jade Ramiso &lt; raniejaderamiso&lt; at &gt;gmail.com&gt; wrote: </pre> Oliver Ruebenacker 2013-05-24T15:35:29 http://permalink.gmane.org/gmane.comp.lang.scala/29446 <pre>Not an answer, but this might give some hints: scala -Ywarn-adapted-args a(1, "String", "Hello") &lt;console&gt;:9: warning: Adapting argument list by creating a 3-tuple: this may not be what you want. signature: a(x: Any): Unit given arguments: 1, "String", "Hello" after adaptation: a((1, "String", "Hello"): (Int, String, String)) a(1, "String", "Hello") ^ Bye, Simon </pre> Simon Ochsenreither 2013-05-24T15:32:10 http://permalink.gmane.org/gmane.comp.lang.scala/29445 <pre> Well, you have seen the failing tests and can look into the implementation of HotSpot if you like. I'm also not happy with the current situation, but my unhappiness won't fix the issues. </pre> Simon Ochsenreither 2013-05-24T15:29:52 http://permalink.gmane.org/gmane.comp.lang.scala/29444 <pre>Hi Victor I've seen catching regular Exceptions leading to data corruption, but haven't ever seen someone terminating the vm because of SOE or OOME (except the mentioned kill -9 %p trick for hadoop workers) On the other hand user input in a regular web application may lead to OOME or even SOE while handling e.g. http request and it is unsound to assume that we should abandon processing the request without a regular exception handling or kill the vm. Aleh On Wednesday, May 22, 2013 10:26:54 PM UTC+3, √iktor Klang wrote: </pre> Aleh Aleshka 2013-05-24T15:08:13 http://permalink.gmane.org/gmane.comp.lang.scala/29443 <pre>Given this method: def a(x: Any) { println(x) } You could call the method a with multiple parameters. e.g: a(1, "String", "Hello") # same as a((1, "String", "Hello")) I'm curious about the handling of this. Is it a language feature? I can't find any online resource pertaining to it. </pre> Ranie Jade Ramiso 2013-05-24T15:06:07 http://permalink.gmane.org/gmane.comp.lang.scala/29442 <pre> AFAIK https://github.com/sbt/sbt-scalashim provides just the sys package for 2.8 and nothing more. Last changes have been a year ago. What I would like are officially supported backports. </pre> wookietreiber 2013-05-24T14:39:10 http://permalink.gmane.org/gmane.comp.lang.scala/29441 <pre>On Fri, May 24, 2013 at 4:27 PM, wookietreiber &lt; kizkizzbangbang&lt; at &gt;googlemail.com&gt; wrote: Why is sbt-scalashim not a solution for this problem for most cases? </pre> Johannes Rudolph 2013-05-24T14:33:52 http://permalink.gmane.org/gmane.comp.lang.scala/29440 <pre>Dear all, This may come a little late (but hopefully not too late): Would it be possible to backport certain / all SIPs which have been accepted for 2.10 to 2.9 to ease cross compilation? (like SIP-14 already has to 2.9.3) If someone uses, say language imports and implicit classes in a 2.10 project and wants to cross compile and release for 2.9, one would have to change back the code to full 2.9 compatibility to make this possible (drop all implicit classes and use the old class + implicit def, drop all language imports) or -- even worse -- create a separate branch with the alternate code (aka maintenance hell). For this reason I'm humbly asking for backports for the features introduced in 2.10 to allow the usage of these features in projects while still having no maintenance problems compiling for older versions. I have also already searched for and located an issue [SI-6694][1] which was unfortunately closed prematurely without much discussion. [1]: https://issues.scala-lang.org/browse/SI-6694 </pre> wookietreiber 2013-05-24T14:27:00 http://permalink.gmane.org/gmane.comp.lang.scala/29439 <pre> Hello guys, I was the writer of the report (the Scala part). Actually, it was done almost two years ago, but it is only made public now, so that's explain the old version of Scala/JVM. Also note that the format and some recommandation were dictated by a previour report done on Java / JVM securiy model, so if some things seems strange, it may come from that. All in all, if you have any question, please ask ! Cheers, </pre> Francois 2013-05-24T10:44:45 http://permalink.gmane.org/gmane.comp.lang.scala/29438 <pre>Thank you very much! I think some of the issues could at least be converted into a compiler warning (e. g. “Warning 17: primary constructor code may be spread all over the class definition ”). Bye, Simon </pre> Simon Ochsenreither 2013-05-24T10:32:58 http://permalink.gmane.org/gmane.comp.lang.scala/29437 <pre>Hi all, For those of you that understand french, an interesting study on security and safety in functional programming languages was published by ANSSI (French national agency for information security) [1]. The study presents 7 functional languages: Scala, OCaml, F#, Haskell, LISP, Scheme and Erlang and analyses 3 of them: Scala, OCaml and F# For Scala, the analysis focuses on two aspects: - the development environment and its impact on security - the constructs and their impact on security and safety Of course, this report for Scala relates to a previous study on the Java platform [2], which is not repeated here. The evaluated version is Scala in its version 2.8.1 on the Oracle HotSpot JVM in its version 1.6.25, which is quite old and some points raised are no relevant anymore (e.g. catching `Throwable`). Many warnings and advices are actually good practices already given by the coding guidelines. Some other points are only relevant when dealing with applications in which security is critical (well, t</pre> Lucas Satabin 2013-05-24T10:24:03 http://permalink.gmane.org/gmane.comp.lang.scala/29435 <pre> Define rare. But should we penalize every use case of scala.util.Try ? Penalize in what way? Penalize heap and stack abuse? Data corruption? Cheers, √ </pre> √iktor Ҡlang 2013-05-22T19:26:54 http://permalink.gmane.org/gmane.comp.lang.scala/29434 <pre>I guess OOME and SOE could leave vm in inconsistent state in some rare cases. Obviously even Exception thrown from user code can potentially leave it in this state and we can't assume that it's safe to proceed.. But should we penalize every use case of scala.util.Try ? What is the worst thing that could happen if Try (and other users of NonFatal) was catching OOME and SOE? Thanks, Aleh. On Wednesday, May 22, 2013 3:35:15 AM UTC+3, √iktor Klang wrote: </pre> Aleh Aleshka 2013-05-22T19:18:53 http://permalink.gmane.org/gmane.comp.lang.scala/29433 <pre>Can you give the name and the versions of the VMs in question? </pre> Simon Ochsenreither 2013-05-22T15:55:43 http://permalink.gmane.org/gmane.comp.lang.scala/29432 <pre>aha! finally I found a reproducer that works on both JVMs that I tried. Acquired by One n: 94 -- must be zero SOE in Two &lt; at &gt; level 178 caught &lt; at &gt; 178; sum: 1275 Two entering sub: iteration 34783 Acquired by Two n: 44 SOE in One &lt; at &gt; level 228 caught &lt; at &gt; 228; sum: 1275 One entering sub: iteration 34783 Acquired by One n: 93 SOE in Two &lt; at &gt; level 179 caught &lt; at &gt; 179; sum: 1275 Two entering sub: iteration 34784 Acquired by Two n: 44 The trick is to make the lock on which synchronization occurs fat. If you are curious, I can paste the reproducer; but I wanted just to make a point that no JVM is likely to be immune to this problem and we can't say it is a bug in one JVM. Alex 2013/5/22 Björn Antonsson &lt;bjorn.antonsson&lt; at &gt;typesafe.com&gt; </pre> Sassa Nf 2013-05-22T15:29:02 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.lang.scala