# leak Published articles for leak. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Meta's Next-gen MR Headset Appears to Have Leaked Ahead of Connect DevFeed: [Meta's Next-gen MR Headset Appears to Have Leaked Ahead of Connect]() Original publisher: [Read original article]() Author: Scott Hayden Published: 2026-09-11T08:53:50Z Content type: news Language: en Sources: [Road to VR]() Topics: [Meta](), [FIRST]() Tags: [leak](), [meta](), [meta-quest-3-news-reviews](), [news](), [os](), [sensors](), [xr-industry-news]() ### AI overview Images and video appearing to show Meta's Project Phoenix mixed reality headset have reportedly leaked ahead of Meta Connect. The material suggests a slim standalone headset with prescription lenses, hand and eye tracking, multiple sensors, and a cable-tethered compute unit, while its official name, price, and release date remain unknown. ### Source excerpt Images of Meta's 'Project Phoenix' mixed reality headset appear to have leaked ahead of its anticipated unveiling at Connect later this month. The News Serial leaker 'Luna' appears to have found video within Quest's Horizon OS showing off the headset's prescription lenses, which are apparently set to be released in partnership by Meta's official prescription [...] The post Meta's Next-gen MR Headset Appears to Have Leaked Ahead of Connect appeared first on Road to VR. ## Report: 13TB of Steam data leaked after users access 'publicly accessible endpoint' DevFeed: [Report: 13TB of Steam data leaked after users access 'publicly accessible endpoint']() Original publisher: [Read original article]() Author: Bryant Francis Published: 2026-08-31T15:07:37Z Content type: news Language: en Sources: [gamedeveloper]() Topics: [data](), [Security](), [Server]() Tags: [breach](), [games](), [leak](), [pre-release](), [report](), [security]() ### AI overview A reported 13TB leak exposed Steam-related data uploaded between 2003 and 2013, including early Valve game builds and screenshots as well as beta builds from other publishers. The data was reportedly accessible through a public endpoint, though the source and scope of the breach remain unclear. ### Source excerpt The leaked data apparently includes beta builds and screenshots of pre-release Valve titles--and games from other publishers like EA and WB Games. ## \[webapps\] Duplicati 2.2.0.3 - JWT Signing Key Leak DevFeed: [\[webapps\] Duplicati 2.2.0.3 - JWT Signing Key Leak]() Original publisher: [Read original article]() Author: Gabriel Rodrigues Published: 2026-08-17T00:00:00Z Content type: article Language: en Sources: [Exploit-DB.com RSS Feed]() Topics: [JSON Web Tokens](), [Exploit]() Tags: [exploit](), [jwt](), [leak](), [multiple](), [platform](), [signing](), [webapps]() ### AI overview An exploit listing identifies a JWT signing key leak in Duplicati 2.2.0.3 and describes it as a web application exploit for multiple platforms. ### Source excerpt Duplicati 2.2.0.3 - JWT Signing Key Leak ## Xiaomi Smart Storage NAS Revealed DevFeed: [Xiaomi Smart Storage NAS Revealed]() Original publisher: [Read original article]() Author: Rob Andrews Published: 2026-08-03T16:00:11Z Content type: article Language: en Sources: [NAS Compares]() Topics: [Hardware](), [Specifications](), [QNAP](), [Synology]() Tags: [2-bay-nas](), [capacity](), [china](), [consumer](), [crowdfunding](), [hardware](), [home-nas](), [hyperos](), [launch](), [leak](), [nas](), [nas-2026](), [nas-news](), [network-attached-storage-nas](), [news](), [news-2026](), [private-cloud](), [product](), [qnap](), [qnap-2026](), [qnap-alternative](), [qnap-news](), [realtek-rtd1619b](), [specifications](), [storage](), [synology](), [synology-2026](), [synology-alternative](), [synology-news](), [uncategorised](), [xiaomi](), [xiaomi-nas](), [xiaomi-smart-storage](), [xiaomi-youpin]() ### AI overview Xiaomi Smart Storage is a two-bay consumer NAS launched in China through Xiaomi Youpin crowdfunding. The article describes its family-focused storage use cases, bundled-drive pricing, and leaked engineering-sample hardware specifications, while distinguishing official details from unconfirmed specifications. ### Source excerpt Xiaomi has now officially moved into the home NAS market with Xiaomi Smart Storage, a two-bay consumer storage box that is being launched in China through Xiaomi Youpin crowdfunding. The product is being positioned less like a traditional enthusiast NAS and more like a family storage appliance for phone backup, photo management, files, and home [...] ## Managing Environment Variables and Secrets in DevOps DevFeed: [Managing Environment Variables and Secrets in DevOps]() Original publisher: [Read original article]() Author: Pramodh Kumar M Published: 2026-08-01T13:00:47Z Content type: tutorial Language: en Sources: [Kubernetes - KodeKloud Blog | DevOps, Cloud, Kubernetes, AI Tutorials & More]() Topics: [DevOps](), [configuration](), [GitGuardian](), [GitHub](), [Terraform](), [Kubernetes]() Tags: [ci-cd-secrets-management](), [cloud](), [collaboration](), [collaboration-tools](), [configuration](), [container](), [crash](), [devops](), [devsecops](), [dynamic-secrets](), [env-file-security](), [environment-variables](), [gitguardian](), [github](), [hardcoded-credentials](), [hashicorp-vault](), [jira](), [kubernetes](), [kubernetes-secrets](), [leak](), [managing-environment-variables-and-secrets](), [rotation](), [safety](), [sealed-secrets](), [secret-rotation](), [secret-scanning](), [secrets](), [secrets-management-best-practices](), [security](), [storage](), [terraform](), [vault]() ### AI overview A guide to managing environment variables and secrets in DevOps. It explains how secrets escape through repositories, processes, crash reports, containers, collaboration tools, Kubernetes Secrets, and Terraform state, and discusses storage, access controls, lifecycles, and rotation. ### Source excerpt Nearly 29 million secrets were pushed to public GitHub in a single year, and most teams still discover their own leaks by accident. Here is how environment variables actually escape, and what to use instead at each stage. ## July 2026 Updates #1 for XCP-ng 8.3 LTS DevFeed: [July 2026 Updates #1 for XCP-ng 8.3 LTS]() Original publisher: [Read original article]() Author: Philippe Coval Published: 2026-07-28T14:32:38Z Content type: release Language: en Sources: [XCP-ng Blog]() Topics: [Security](), [Vulnerabilities](), [Memory Leaks]() Tags: [2026](), [iso](), [leak](), [lts](), [regression](), [release](), [security](), [update](), [updates]() ### AI overview This release provides security and maintenance updates for XCP-ng 8.3 LTS. It updates Xen to address multiple security advisories, fixes a XAPI regression that caused VBD leaks, and includes minor changes needed to build an updated installer ISO. ### Source excerpt This release batch contains a security update for Xen. This update also brings a fix for a XAPI regression causing VBD leaks. Other minor changes were needed to build an updated XCP-ng 8.3 LTS installer (ISO). ## The real AI risk is inside the labs DevFeed: [The real AI risk is inside the labs]() Original publisher: [Read original article]() Published: 2026-07-28T09:00:11Z Content type: opinion Language: en Sources: [Antirez]() Topics: [Artificial Intelligence](), [Frontier AI](), [Large Language Model](), [incident](), [Security](), [Maintainers]() Tags: [ai](), [frontier-ai](), [incident](), [leak](), [llms](), [maintainers](), [open-source](), [openai](), [security]() ### AI overview The article argues that the most serious AI risks are more likely to emerge within frontier AI laboratories through accidents, misuse, or leaks than through the public release of open-weight models. It also discusses how restricted access to defensive LLM capabilities could worsen cybersecurity risks. ### Source excerpt Amodei in his latest blog post wrote a mix of agreeable things and things that I believe misrepresent where the real risk of AI is located. I want to focus my attention on why, among all the risks, open weight models constitute the mildest one. I write these words as a person who strongly believes AI may be very dangerous in the near future: 1. Exactly like what happened during the OpenAI / HF incident (which was a joke, but focus on the modalities, not the outcomes), the first serious AI incident is very likely to happen *inside* the walls of frontier AI labs, while testing a new model, or while the AI lab employees, or the few externals who have access, do something wrong compared to the expected power of the model. 2. Closed models that will never even be opened to the public will be just a few TBs of data. All you need to leak one is a single person with access and the wrong goals, and you are back in the situation of open models. Open models are released *after* testing, and after similarly capable models were already available for some time under an API. The real risk is leaks, not releases, and leaks happen inside frontier companies. 3. As Amodei says, open models, once LLMs are dangerous enough in fields like biology, can be trained on a corpus ablated of certain branches of science, while still being useful for a number of other things. The limited context window of a model that lacks strong pre-training in certain domains is a strong protection even if the model is otherwise very capable. We are currently not in a place where open models can constitute that kind of danger. 4. In the context of cyber security, *not* having widespread access to the defensive security and bug seeking provided by LLMs creates exactly the "LLMs as a weapon" problem. It is already happening: open source maintainers, if they are out of some cyber program, can't find all the security bugs they could, while people with the right interests will be able to access frontier cyber model ## How Claude Code's Source Map Was Shipped and Rebuilt by the Community DevFeed: [How Claude Code's Source Map Was Shipped and Rebuilt by the Community]() Original publisher: [Read original article]() Author: Engineer's Codex Published: 2026-04-01T06:25:24Z Content type: article Language: en Sources: [Engineer's Codex]() Topics: [Claude Code](), [anthropic](), [Code generation](), [GitHub](), [Artificial Intelligence](), [Code review]() Tags: [ai](), [anthropic](), [claude-code](), [codegen](), [github](), [leak](), [npm](), [openai](), [post-mortems]() ### AI overview The article examines how Anthropic accidentally included a sourcemap in a Claude Code npm package, how the exposed code was mirrored and ported to other languages, and the resulting copyright questions around AI-assisted clean-room rebuilding. ### Source excerpt Engineer's Codex is a publication about real-world software engineering. ## Stressing the JVM GC on Android DevFeed: [Stressing the JVM GC on Android]() Original publisher: [Read original article]() Author: Amanjeet Singh Gurtatta Published: 2024-03-10T08:49:55Z Content type: tutorial Language: en Sources: [Amanjeet Singh]() Topics: [Android](), [Java](), [Code](), [now-in-android]() Tags: [adb](), [android](), [android-vitals](), [anr](), [fragmentation](), [gc](), [java](), [leak](), [memory](), [memory-leak](), [mobile](), [mobile-performance](), [now-in-android](), [outofmemory](), [performance](), [stress](), [stresstest]() ### AI overview This tutorial describes GCStress, a Java application that deliberately creates garbage-collection pressure through repeated random byte-array allocations and cache removals. It explains how to integrate it into Google's Now in Android app, trigger it with an Android broadcast and adb, and observe effects such as skipped UI frames, possible ANRs, and potential out-of-memory errors. ### Source excerpt This post talks about a way to stress Java garbage collector. ## Discovering iOS memory leaks: A case study with Firefox app II DevFeed: [Discovering iOS memory leaks: A case study with Firefox app II]() Original publisher: [Read original article]() Author: Amanjeet Singh Gurtatta Published: 2024-02-24T11:22:22Z Content type: article Language: en Sources: [Amanjeet Singh]() Topics: [Firefox](), [iOS](), [Memory Leaks](), [Open Source](), [Pull Request](), [GitHub](), [Refactoring]() Tags: [firefox](), [github](), [ios](), [leak](), [memory](), [memory-leak](), [memory-leaks](), [mobile-performance](), [open-source](), [release]() ### AI overview A case study of contributing a memory-leak fix to Firefox for iOS. The article describes the pull-request process, an initially unmerged approach, the eventual fix involving a UI kit retain cycle, and lessons about coordinating with open-source maintainers. ### Source excerpt Discover my experience in contributing to Firefox ios fixing their memory leaks ## Discovering iOS memory leaks: A case study with Firefox app DevFeed: [Discovering iOS memory leaks: A case study with Firefox app]() Original publisher: [Read original article]() Author: Amanjeet Singh Gurtatta Published: 2023-12-25T21:07:16Z Content type: tutorial Language: en Sources: [Amanjeet Singh]() Topics: [iOS](), [Memory Leaks](), [Command-line interface](), [Firefox](), [App](), [Monitoring]() Tags: [command-line](), [crashlytics](), [firebase](), [firefox](), [ios](), [leak](), [memory](), [memory-leak](), [memory-leaks](), [tool]() ### AI overview A case study on detecting and prioritizing memory leaks in iOS apps. It explains automatic reference counting, recommends prioritizing production leaks and monitoring core flows, and uses a Firefox iOS app with UI tests and the macOS leaks command-line tool. ### Source excerpt Discover how to efficiently detect and manage memory leaks in iOS apps using the leaks command line tool with example ## Apollo Client 3.9 Feature Spotlight - The memory story DevFeed: [Apollo Client 3.9 Feature Spotlight - The memory story]() Original publisher: [Read original article]() Author: Lenz Weber-Tronic Published: 2023-12-20T16:02:32Z Content type: article Language: en Sources: [Apollo Blog]() Topics: [apollo-client](), [Memory Leaks](), [Caching](), [Open Source](), [Maintainers]() Tags: [apollo-client](), [cache](), [feature](), [issue](), [leak](), [memory](), [memory-leak](), [memory-leaks](), [open-source](), [spotlight]() ### AI overview Apollo Client 3.9 is released in beta with fixes for various memory leaks, more granular control over internal cache sizes, and deprecation of canonizeResults because of a conceptual, non-fixable memory leak. The article also asks users to help determine appropriate default cache sizes. ### Source excerpt Apollo Client 3.9 is out in beta now, and it fixes various memory leaks, adds granular control over internal cache sizes, and deprecates the canonizeResults option due to a conceptual and non-fixable memory leak associated with it. We want your help to find the correct default cache sizes - see the last paragraph for details on that. The memory story Sometimes, in an open source project, you have that issue that sticks around for a long time because it's not clear how you would tackle it. ## Avoid Java double brace initialization DevFeed: [Avoid Java double brace initialization]() Original publisher: [Read original article]() Author: Pierre-Yves Ricau Published: 2023-06-27T20:58:00Z Content type: tutorial Language: en Sources: [Py's blog]() Topics: [Java](), [Code](), [Android]() Tags: [android](), [class](), [classes](), [code](), [constructor](), [crash-reporting](), [gc](), [global](), [implementation](), [java](), [leak](), [leakcanary](), [lifecycle](), [memory](), [memory-leak](), [object](), [patterns](), [subclass]() ### AI overview This tutorial explains how Java double brace initialization can cause memory leaks. An anonymous HashMap subclass implicitly retains its outer Activity, so a breadcrumb stored by a singleton BugSnag client can keep a destroyed Android Activity in memory. The article recommends avoiding the pattern and using explicit initialization or Kotlin. ### Source excerpt TL;DR Avoid doing this: new HashMap() {{ put("key", value); }}; Leak Trace I was recently looking at the following leak trace from LeakCanary: ┬─── │ GC Root: Global variable in native code │ ├─ com.bugsnag.android.AnrPlugin instan... ## Callback leaks: cancel your Picasso requests! DevFeed: [Callback leaks: cancel your Picasso requests!]() Original publisher: [Read original article]() Author: Pierre-Yves Ricau Published: 2023-01-17T21:06:14Z Content type: tutorial Language: en Sources: [Py's blog]() Topics: [Picasso](), [Android](), [Code]() Tags: [android](), [android-app-development](), [how-to](), [leak](), [leakcanary](), [memory-leak](), [performance](), [picasso]() ### AI overview This article investigates an Android memory leak caused by an in-flight Picasso image-loading request retaining a detached UI component through a custom callback. It explains how to read the leak trace and recommends canceling requests or using tags when the UI goes away. ### Source excerpt 👋 Hi, this is P.Y., I work as an Android Engineer at Block. Every month I organize an internal Ensemble Leak Hunting session where we look at the top leaks reported by LeakCanary to learn how to read ## Investigation of a Gradle and IntelliJ IDEA Memory Leak DevFeed: [Investigation of a Gradle and IntelliJ IDEA Memory Leak]() Original publisher: [Read original article]() Author: Pierre-Yves Ricau Published: 2022-10-12T17:26:46Z Content type: tutorial Language: en Sources: [Py's blog]() Topics: [Gradle](), [Memory Leaks](), [IntelliJ IDEA](), [Java](), [Graphs]() Tags: [garbage-collection](), [gc](), [gradle](), [graph](), [idea](), [intellij](), [java](), [leak](), [memory](), [memory-leak](), [performance]() ### AI overview A team investigation examines a Gradle process memory leak during project import in IntelliJ IDEA. The article describes heap analysis using dominator trees, pending finalization, and paths from GC roots. ### Source excerpt 👋 Hi, this is P.Y., I work as an Android Engineer at Block. This article shares a team investigation by Tony Robalik, Pablo Baxter, Roger Hu and myself into a recent Gradle / IntelliJ memory leak. O ## Leak investigation: Rx disposal race in SQLDelight DevFeed: [Leak investigation: Rx disposal race in SQLDelight]() Original publisher: [Read original article]() Author: Py ⚔ Published: 2021-05-17T22:10:41Z Content type: tutorial Language: en Sources: [Py ⚔]() Topics: [RxJava](), [Code](), [implementation]() Tags: [android](), [code](), [coding](), [community](), [development](), [engineering](), [implementation](), [inclusive](), [leak](), [rxjava](), [software](), [sqldelight](), [thread]() ### AI overview This article investigates a memory leak caused by a disposal race in SQLDelight's RxJava integration. The implementation sets the disposable before adding the query listener, so a subscription that is already disposed can add a listener that is never removed. The article recommends checking listener and disposable ordering and avoiding unnecessary scheduler calls for observables originating from Observable.create(). ### Source excerpt Header image: The In-Between by Romain Guy. In this blog we'll look into how an easy mistake when using Observable.create() can lead to subtle leaks. I recently investigated the following leak, which I couldn't reproduce systematically: ┬─── ... ├─ com.example.hockey.PlayerQueries$selectAllQuery instance │ ↓ Query.listeners │ ~~~~~~~~~ ├─ java.util.concurrent.CopyOnWriteArrayList instance │ ↓ CopyOnWriteArrayList.array │ ~~~~~ ├─ java.lang.Object[] array │ ↓ Object[].[0] │ ~~~ ├─ sqldelight.runtime.rx.QueryListenerAndDisposable instance │ Retaining 4.3 kB in 56 objects │ ↓ QueryListenerAndDisposable.emitter │ ~~~~~~~ ... RxJava observer chain ├─ com.example.hockey.PlayersView$onAttachedToWindow$1 instance │ Anonymous class implementing io.reactivex.functions.Function │ ↓ PlayersView$onAttachedToWindow$1.this$0 │ ~~~~~~ ╰-> com.example.hockey.view.PlayersView instance Leaking: YES (View.mContext references a destroyed activity) In the above leaktrace, PlayerQueries$selectAllQuery is a generated SQLDelight query. Our PlayersView is listening for updates to that query while the view is attached by leveraging Query.asObservable(). Once the view is detached, the observable chain is disposed and the query is expected to let go of the corresponding listener. I inspected the heap dump and found that the view was indeed detached, the observable chain was correctly disposed, and yet the QueryListenerAndDisposable listener had not been removed from the query. Let's look at the Query.asObservable() implementation: fun Query.asObservable(): Observable> { return Observable.create(QueryOnSubscribe(this)) } private class QueryOnSubscribe( private val query: Query ) : ObservableOnSubscribe> { override fun subscribe(emitter: ObservableEmitter>) { val listener = QueryListenerAndDisposable(emitter, query) emitter.setDisposable(listener) query.addListener(listener) emitter.onNext(query) } } private class QueryListenerAndDisposable) Original publisher: [Read original article]() Author: Py ⚔ Published: 2020-10-30T00:13:40Z Content type: tutorial Language: en Sources: [Py ⚔]() Topics: [Android Studio](), [Memory Leaks](), [Android](), [Code]() Tags: [android](), [android-studio](), [coding](), [community](), [development](), [engineering](), [false-positive](), [inclusive](), [leak](), [leakcanary](), [memory](), [memory-leaks](), [software]() ### AI overview The article compares Android Studio's Activity/Fragment leak filtering with LeakCanary's lifecycle-based detection. It explains that Android Studio may flag newly created or cached Fragments as potential leaks, while LeakCanary watches destroyed objects and checks whether they remain retained after garbage collection. ### Source excerpt I recently came across this comment in a post: The thing really annoying about LeakCanary or Android Studio, most of the time leaks identified by LeakCanary do not appear in Profiler/Memory/memory leaks, I wonder if LeakCanary is showing false positives or Android Studio is missing positives. That's a good question, let's dig into code and figure this out! False positive leaks in Android Studio Before answering the question, we need to talk about where the idea of false positive leaks comes from: Android Studio. That warning was originally a longer description: Activity and Fragment instances that might be causing memory leaks. For Activities, these are instances that have been destroyed but are still being referenced. For Fragments, these are instances that do not have a valid FragmentManager but are still being referenced. Note, these instance might include Fragments that were created but are not yet being utilized. The documentation provides more insights on false positive leaks: In certain situations, such as the following, the filter might yield false positives: A Fragment is created but has not yet been used. A Fragment is being cached but not as part of a FragmentTransaction. The phrasing is vague but it looks like false positive leaks only applies to Fragments. Android Studio leak filtering Android Studio dumps and analyzes the heap when you press the Dump Heap icon. Leaking instances are displayed by enabling the "Activity/Fragment Leaks" filter, which updates the bottom panel to only show leaking instances. The filtering is performed by ActivityFragmentLeakInstanceFilter: const val FRAGFMENT_MANAGER_FIELD_NAME = "mFragmentManager" /** * A Fragment instance is determined to be potentially leaked if * its mFragmentManager field is null. This indicates that the * instance is in its initial state. Note that this can mean that * the instance has been destroyed, or just starting to be * initialized but before being attached to an activity. The * latter gives us ## Investigating Memory Leaks in Square POS on Android Q DevFeed: [Investigating Memory Leaks in Square POS on Android Q]() Original publisher: [Read original article]() Author: P-Y Ricau Published: 2019-07-03T19:00:00Z Content type: article Language: en Sources: [Square Corner Blog RSS Feed]() Topics: [Android](), [Memory Leaks](), [debugging](), [Large Screen]() Tags: [android](), [debugging](), [engineering](), [leak](), [leakcanary](), [lifecycle](), [memory](), [memory-leaks](), [view]() ### AI overview The article investigates unusually high memory leaks observed while testing Square POS on Android Q, focusing on leak traces involving an attached view and a destroyed activity. It also explains how LeakCanary 2 uses lifecycle heuristics when interpreting such traces. ### Source excerpt Debugging leaks for Square POS in Android Q ## Goroutine Leaks - The Abandoned Receivers DevFeed: [Goroutine Leaks - The Abandoned Receivers]() Original publisher: [Read original article]() Published: 2018-12-19T00:00:00Z Content type: tutorial Language: en Sources: [William Kennedy]() Topics: [Go Language](), [Memory Leaks]() Tags: [ardan-labs](), [blog](), [channel](), [developers](), [go](), [go-programming](), [golang](), [goroutines](), [leak](), [memory](), [memory-leaks](), [pipeline](), [programming]() ### AI overview This Go programming article explains a goroutine leak scenario in which multiple goroutines remain blocked waiting to receive values that will never be sent. It presents a batch-processing program using input and output channels, a goroutine worker pool, and a pipeline. ### Source excerpt Introduction Goroutine Leaks are a common cause of memory leaks in Go programs. In my previous post, I presented an introduction to Goroutine leaks and provided one example of a common mistake that many Go developers make. Continuing that work, this post presents another scenario on how Goroutines could be leaked. Leak: The Abandoned Receivers For this leak example you will see multiple Goroutines blocked waiting to receive values that will never be sent. ## The Tale of a Go Resource Leak DevFeed: [The Tale of a Go Resource Leak]() Original publisher: [Read original article]() Author: Alec Holmes Published: 2017-07-11T19:31:01Z Content type: article Language: en Sources: [Square Corner Blog RSS Feed]() Topics: [Go Language](), [Memory Leaks](), [bug](), [configuration](), [Code]() Tags: [bug](), [configuration](), [engineering](), [garbage-collection](), [go](), [leak](), [memory]() ### AI overview A Square Go service developed sharply higher memory and CPU use after bugs caused per-request metadata to be retained for almost 17 hours. The investigation traced the issue to uncanceled Go contexts in an internal request-handling framework, combined with a client timeout misconfiguration. ### Source excerpt The Tale of a Go Resource Leak ## Questions of the Week 34 DevFeed: [Questions of the Week 34]() Original publisher: [Read original article]() Author: Shai Almog Published: 2016-12-01T00:00:00Z Content type: opinion Language: en Sources: [CodeName One]() Topics: [Code](), [Android](), [Java](), [Disk image](), [JavaScript]() Tags: [abstraction](), [android](), [experimental](), [implementation](), [java](), [javascript](), [leak](), [simulator](), [storage]() ### AI overview A weekly digest discusses selected developer questions, including Storage to FileSystemStorage mapping, abstraction leakage, experimental Java 8 operation support in native Android code, and JavaScript code that must run after page load. ### Source excerpt While I find these posts useful I think it's time to re-think this post which is overly mechanical and only post interesting news from the week rather than "everything". So this week we'll try something new, I'll discuss the news in general and the questions/answers I find valuable only. I'll ignore the other questions and this should make the post more "digestible". peopletookallthegoodnames asked about Storage to FileSystemStorage mapping here. This is a problematic subject. Storage is an abstraction, the fact that the implementation can be seen sometimes within the FileSystemStorage is a "leak" within the abstraction. ## Become a Firebase Taskmaster! (Part 2: Choosing the Best Options) DevFeed: [Become a Firebase Taskmaster! (Part 2: Choosing the Best Options)]() Original publisher: [Read original article]() Author: Doug Stevenson Published: 2016-09-20T00:00:00Z Content type: tutorial Language: en Sources: [Firebase Blog]() Topics: [Firebase](), [Android](), [API]() Tags: [android](), [api](), [best-practices](), [firebase](), [java](), [leak](), [lifecycle](), [main-thread](), [tutorials]() ### AI overview This tutorial examines listener options for the Play Services Task API, including how listeners are invoked on the main thread and how an in-progress Task can retain an Activity after onDestroy(), potentially causing an Activity leak. ### Source excerpt News, tutorials, and updates from the Firebase team. ## Tracking down a memory leak in Ruby's EventMachine DevFeed: [Tracking down a memory leak in Ruby's EventMachine]() Original publisher: [Read original article]() Author: Nelson Elhage Published: 2013-03-07T13:13:37Z Content type: tutorial Language: en Sources: [Nelson Elhage]() Topics: [Memory Leaks](), [Ruby](), [debugging](), [Post Mortem](), [Monitoring](), [stripe]() Tags: [debugging](), [gdb](), [leak](), [memory](), [memory-leak](), [monitoring](), [post-mortem](), [ruby](), [techniques](), [tools]() ### AI overview This article describes how Stripe investigated a gradual memory leak in a Ruby service using EventMachine. It covers monitoring and process restarts as a workaround, then explores post-mortem analysis, gdb, the Ruby C API, garbage-collection hooks, and Ruby ObjectSpace to determine whether Ruby-level objects explained the service's multi-gigabyte memory use. ### Source excerpt At Stripe, we rely heavily on ruby and EventMachine to power various internal and external services. Over the last several months, we've known that one such service suffered from a gradual memory leak, that would cause its memory usage to gradually balloon from a normal ~50MB to multiple gigabytes. It was easy enough to work around the leak by adding monitoring and restarting the process whenever memory usage grew too large, but we were determined to track down the root cause.