wu :: forums
« wu :: forums - Storing stack backtraces »

Welcome, Guest. Please Login or Register.
May 1st, 2025, 8:10pm

RIDDLES SITE WRITE MATH! Home Home Help Help Search Search Members Members Login Login Register Register
   wu :: forums
   riddles
   cs
(Moderators: SMQ, Eigenray, Grimbal, ThudnBlunder, william wu, Icarus, towr)
   Storing stack backtraces
« Previous topic | Next topic »
Pages: 1  Reply Reply Notify of replies Notify of replies Send Topic Send Topic Print Print
   Author  Topic: Storing stack backtraces  (Read 981 times)
pharaoh
Newbie
*





   


Gender: male
Posts: 50
Storing stack backtraces  
« on: Feb 19th, 2009, 10:56pm »
Quote Quote Modify Modify


Hello fellas,
 
This is not an interview question, rather a real problem I am trying to solve off late.
 
I am writing a tool, which reports detected memory leaks in programs. I will spare the rest of details.
 
At  some predetermined points in program , I collect the stack trace and store it in a hash table. This happens way too often and the amount of data I end up storing increases significantly. I do not store duplicate backtraces though. When need arises I hash these stack traces and take some decisions.  
 
Now the real problem,  if you look carefully at the stack traces in larger programs, you will notice that for a N level deep stack trace i.e. N frames in stack trace, first few frames are same many times.  
 
Two different stack trace might look like this:
 
stack 1        stack 2
0x1234      0xb7841
0xabcd      0xabcd
0x0xyz       0x0xyz
0x8000      0x8000
 
Here only the top most frame differes, but these are two different execution paths and currently I store them as seperate. There is scope here for reducing the redundancy
by storing only the different elements and somehow relating the same elements in different nodes.
 
I vaguely remember reading somewhere that some graph kind of data structure being used for this kind of purpose, but I dont want to break the existing hash table infrastructure, for some time to come.
 
I am looking some kind of compression mechanism here.
Any alternate approaches to do the same thing?
 
 
 
 
IP Logged

Cogito ergo sum.

-Pharaoh
cuckoo
Junior Member
**





   


Gender: male
Posts: 57
Re: Storing stack backtraces  
« Reply #1 on: Feb 20th, 2009, 12:14am »
Quote Quote Modify Modify

May be you can use the "trie" structure to store the paths. And for trie structure, there are many methods for its compact representation, such as the double array trie. Smiley
IP Logged
towr
wu::riddles Moderator
Uberpuzzler
*****



Some people are average, some are just mean.

   


Gender: male
Posts: 13730
Re: Storing stack backtraces  
« Reply #2 on: Feb 20th, 2009, 12:39am »
Quote Quote Modify Modify

Perhaps you could store an N-level stack as top plus hashed (N-1)-level stack.
 
hash#5 -> (0xb7841,  hash#3)
hash#4 -> (0x1234,  hash#3)
hash#3 -> (0xabcd,  hash#2)
hash#2 -> (0x0xyz,  hash#1)
hash#1 -> (0x8000,  null)
 
Of course, all this really is is a way to build a graph inside a hash-map.
« Last Edit: Feb 20th, 2009, 2:24am by towr » IP Logged

Wikipedia, Google, Mathworld, Integer sequence DB
pharaoh
Newbie
*





   


Gender: male
Posts: 50
Re: Storing stack backtraces  
« Reply #3 on: Feb 20th, 2009, 1:52am »
Quote Quote Modify Modify


towr,
 
can you please elaborate this a bit more? Not sure I understand it fully.
IP Logged

Cogito ergo sum.

-Pharaoh
towr
wu::riddles Moderator
Uberpuzzler
*****



Some people are average, some are just mean.

   


Gender: male
Posts: 13730
Re: Storing stack backtraces  
« Reply #4 on: Feb 20th, 2009, 2:32am »
Quote Quote Modify Modify

on Feb 20th, 2009, 1:52am, pharaoh wrote:
can you please elaborate this a bit more? Not sure I understand it fully.
It probably didn't help that I wrote it down incorrectly.
I'm suggesting incremental hashing. The hash for N levels consists of hashing the combination of the top element and the hash of the next N-1 levels.
So if the last X levels are the same for several stack, they have the same hash, and you don't need to store them more than once. Each entry of the hashtable gives you the top element and a hash that tells you where to find the rest of the stack. (So it acts like a pointer).
IP Logged

Wikipedia, Google, Mathworld, Integer sequence DB
pharaoh
Newbie
*





   


Gender: male
Posts: 50
Re: Storing stack backtraces  
« Reply #5 on: Feb 20th, 2009, 2:38am »
Quote Quote Modify Modify


Got it now, and it makes a lot of sense to me!! I might end up implementing some thing like this.
 
OTOH, about  the compress/decompress functions I was talking about earlier,  I don't think there will some light weight magic functions to accomplish this. What I mean is, these functions might internally do stuff like incremental hashing etc as you suggest.
IP Logged

Cogito ergo sum.

-Pharaoh
kaka
Newbie
*





   


Gender: male
Posts: 24
Re: Storing stack backtraces  
« Reply #6 on: Mar 28th, 2010, 10:43am »
Quote Quote Modify Modify

I can think of something like this.
 
hash1: -> (top1-> a -> b -> c -> d -> e)
hash2: -> (top2-> f -> g -> {ptr to c } )
hash3: -> (top3-> h -> i -> [ptr to d } )
 
at each node we maintain ref count and increment it when we point to it. We'll free its memory when ref count = 0.
IP Logged
Pages: 1  Reply Reply Notify of replies Notify of replies Send Topic Send Topic Print Print

« Previous topic | Next topic »

Powered by YaBB 1 Gold - SP 1.4!
Forum software copyright © 2000-2004 Yet another Bulletin Board