allocating and freeing attr structs

QNX Newsgroups (Archives) qdn.public.qnxrtp.os
1

Hi:

  1. My resource manager is acting strange. Help would be greatly appreciated.

  2. I have a ‘file system’ RM that has a root-path registered. Open
    requests come in in the form of arbitrary paths (say P1, P2, P3, …
    under the root, ofcourse).

  3. I allocate my extended attr structs for each open and attach the OCB
    to it, with a malloc.

  4. On a close, I free the attr struct.

  5. Simple? The wierd behaviour is that it core dumps if i run a mild
    regression test. (open->close done 50 times). This is reproducable.

  6. But if I dont do the free in the close, things are all fine! I did
    a regresion test of 10,000 times, and it was good.

  7. What could be happening here? I know for a fact that I am not freeing
    any ‘wild’ pointer. Also, I cant pin-point where the coredump happened:
    but it dosent happen in the handlers (open or close) for sure. Is there
    anything about the attr struct that I am missing out?

TIA,
Rommel

2

Rommel Dongre <rdongre@pillardata.com> wrote:

Hi:

  1. My resource manager is acting strange. Help would be greatly appreciated.

  2. I have a ‘file system’ RM that has a root-path registered. Open
    requests come in in the form of arbitrary paths (say P1, P2, P3, …
    under the root, ofcourse).

  3. I allocate my extended attr structs for each open and attach the OCB
    to it, with a malloc.

  4. On a close, I free the attr struct.

  5. Simple? The wierd behaviour is that it core dumps if i run a mild
    regression test. (open->close done 50 times). This is reproducable.

  6. But if I dont do the free in the close, things are all fine! I did
    a regresion test of 10,000 times, and it was good.

  7. What could be happening here? I know for a fact that I am not freeing
    any ‘wild’ pointer. Also, I cant pin-point where the coredump happened:
    but it dosent happen in the handlers (open or close) for sure. Is there
    anything about the attr struct that I am missing out?

TIA,
Rommel

I’ve seen this as well; and I fixed it, but I don’t recall exactly
where. My recollection is that it had to do with unlink(). Something
about having close() do the free when it shouldn’t have. You’re
welcome to take a look at the beginnings of my ramdisk filesystem,
perhaps what you’re seeing is in there… I know it’s kind of vague,
but it’s been a few weeks now since I’ve touched the code…

http://www.parse.com/free/ should get you close.

Cheers,
-RK

–
Robert Krten, PARSE Software Devices +1 613 599 8316.
Realtime Systems Architecture, Books, Video-based and Instructor-led
Training and Consulting at www.parse.com.
Email my initials at parse dot com.

3

Thanks RK. That helped!

I was overriding the io_close_dup handler, assuming that since I always
had 1 attr per ocb, the io_close_dup and io_close_ocb handlers would get
called in conjunctions all the time. <No attr’s are shared, so the only
1 OCB points to it>
Obviously, that’s not happening, for some reason. So, now I override the
io_close_ocb, and it works fine…


Robert Krten wrote:

Rommel Dongre <> rdongre@pillardata.com> > wrote:

Hi:


0. My resource manager is acting strange. Help would be greatly appreciated.

\

  1. I have a ‘file system’ RM that has a root-path registered. Open
    requests come in in the form of arbitrary paths (say P1, P2, P3, …
    under the root, ofcourse).

    \
  2. I allocate my extended attr structs for each open and attach the OCB
    to it, with a malloc.

    \
  3. On a close, I free the attr struct.

    \
  4. Simple? The wierd behaviour is that it core dumps if i run a mild
    regression test. (open->close done 50 times). This is reproducable.

    \
  5. But if I dont do the free in the close, things are all fine! I did
    a regresion test of 10,000 times, and it was good.

    \
  6. What could be happening here? I know for a fact that I am not freeing
    any ‘wild’ pointer. Also, I cant pin-point where the coredump happened:
    but it dosent happen in the handlers (open or close) for sure. Is there
    anything about the attr struct that I am missing out?


    TIA,
    Rommel


    I’ve seen this as well; and I fixed it, but I don’t recall exactly
    where. My recollection is that it had to do with unlink(). Something
    about having close() do the free when it shouldn’t have. You’re
    welcome to take a look at the beginnings of my ramdisk filesystem,
    perhaps what you’re seeing is in there… I know it’s kind of vague,
    but it’s been a few weeks now since I’ve touched the code…

http://www.parse.com/free/ > should get you close.

Cheers,
-RK