diff --git a/debugging-techniques.txt b/debugging-techniques.txt
index d671e06..8a404b9 100644
--- a/debugging-techniques.txt
+++ b/debugging-techniques.txt
@@ -76,4 +76,162 @@ DEBUGGING TECHNIQUES:
 ->  Core Dumped -- and how to look at those files.
     ++++++++++++++++++++++++++++++++++++++++++++++
 
+        When the program crashes and it throws a 
+        message:
 
+        $Segmentation fault(core dumped)
+
+
+        This means that the accessing illegal 
+        memory location and the particular message
+        in parenthesis means that the kernel
+        took the snapshot of the VAS of the program
+        and saved it in a "core" file.
+
+
+        However, this "core" file is only allowed
+        to be generated when the system is configured
+        to allow this operation.
+
+        To check if the core file is allowed to be generated
+        or not we can use...
+
+        Command:
+        $ulimit -a
+
+            This -a flag display all the limits of the system
+            like size of core file allowed to be generated,
+            maximum size of the file allowed, etc.
+
+
+        To particularly see the core file size that is allowed,
+        we can use...
+
+        Command:
+        $ulimit -c
+
+            If it display 0, then core file is now allowed to be
+            generated.
+
+        In order to allow the core files to be generated,
+        we need to set the allowed core file size, by
+        using following command:
+
+        Command:
+        $ulimit -c <size>
+
+            Here, if <size> : unlimited, then there is no 
+            restriction in the allowed core file size which
+            will be generated.
+
+
+        It will generate the core file, but now in order to
+        get the core file we a utility tool called
+
+        "systemd-coredump"
+
+        Install it using package manager.
+
+        To know about the core dump that occured, we can use
+        command of this utility.
+
+        $coredumpctl
+
+        It will display all the core dump that has occured till now
+
+        To display some further detail and location of the coredump
+        that is being store we can use command:
+
+        Command:
+        $coredumpctl dump
+
+
+        Note:
+
+            The core dump file generated is a snapshot of the memory
+            when the program crashed. We can open the coredump file 
+            with gdb using 
+            $coredumpctl gdb
+
+            However, with core dump, we cannot move the execution of
+            the program as it is not running, we can only inspect 
+            the state of the program when it faced the issue.
+
+
+        In order to generate core file in the same directory as where
+        the executable is present we need to do some configuration.
+        After that when the core file is generated in the same 
+        directory as where the executable is present.
+        We can run the core file with executable with debug symbol
+        by running the below command:
+
+        Command:
+        $gdb ./<program> <corefile>
+
+
+-> Core Dumped - gcore for running process:
+   ++++++++++++++++++++++++++++++++++++++++
+
+   To generatea core file for running process.
+
+   We can use gcore, to use it:
+
+   Command:
+   $gcore <PID>
+
+    
+    Run the generated core file with executable with debug symbols
+
+
+    To load the generated core file to gdb use command:
+
+    $gdb -c <corefile>
+
+
+    Note that since core file alone won't show the functions and symbols,etc.
+    Load the file with executable compiled with debug symbols.
+
+
+-> Examining Memory in GDB (also hex):
+   +++++++++++++++++++++++++++++++++++ 
+
+
+   To examine the data structure using examine command.
+
+   we can use command:
+
+   Command;
+   (gdb)x &<object-name>
+
+   We get the output in format as shown below:
+
+    <address of the object in program>: <value of the first byte>
+
+
+    x/nfu
+
+    *   n -> The repeat count is a decimal integer, the default is 1.
+             It specifies how much memory (counting by units u) to 
+             display. If a negative number is specified, memory is examined
+             backward from addr.
+
+    *   f -> The display format is one of the formats used by print('x', 'd',
+             'u', 'o', 't', 'a', 'c', 'f', 's'), 'i'(for machine instructions)
+             and 'm'(for displaying messages). The default is 'x'(hexadecimal)
+             initially. The default changes each time you use either x or print.
+
+    *   u -> The unit size is any of
+
+             b
+                Bytes.
+
+             h
+                Halfwords (two bytes).
+
+             w
+                Words (four bytes). This is the initial default.
+
+             g
+                Giant words (eight bytes)
+
+