<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Bug on Inliniac</title>
    <link>https://inliniac.net/blog/tag/bug/</link>
    <description>Recent content in Bug on Inliniac</description>
    <generator>Hugo</generator>
    <language>en</language>
    <lastBuildDate>Tue, 22 May 2007 21:54:17 +0000</lastBuildDate>
    <atom:link href="https://inliniac.net/blog/tag/bug/feed.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Memory leak fixed in stream4inline</title>
      <link>https://inliniac.net/blog/2007/05/22/memory-leak-fixed-in-stream4inline/</link>
      <pubDate>Tue, 22 May 2007 21:54:17 +0000</pubDate>
      <guid>https://inliniac.net/blog/2007/05/22/memory-leak-fixed-in-stream4inline/</guid>
      <description>&lt;p&gt;A few days ago William told me that if he enabled stream4inline on a busy gateway, Snort_inline would consume all memory within hours. The problem went away when disabling stream4inline, so it made sense that the problem would be in there somewhere.&lt;/p&gt;&#xA;&lt;p&gt;The first suspect was the reassembly cache. The reassembly cache is used to keep a per stream copy of the reassembled packet in memory. While being memory expensive, it greatly speeds up the &lt;em&gt;sliding window&lt;/em&gt; stream reassembly process, especially with small packets. The reason for this being the first and primary suspect is that this is the only place where stream4inline code allocates memory. Reviewing the code however, showed no leaks and adding a debug counter to monitor the memory usage also showed that the leak was not in that code.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
