Thread: Fw: PortalHeapMemoryFree error in OpenACS

Fw: PortalHeapMemoryFree error in OpenACS

From
"Brian Mueller"
Date:
----- Original Message -----=20
From: Brian Mueller=20
To: pgsql-bugs@postgresql.org=20
Sent: Monday, August 07, 2000 10:18 AM
Subject: PortalHeapMemoryFree error in OpenACS




=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
                        POSTGRESQL BUG REPORT TEMPLATE
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D


Your name               :     Brian Mueller
Your email address      :  brian@twotomatoes.com


System Configuration
---------------------
  Architecture (example: Intel Pentium)         : intel 686

  Operating System (example: Linux 2.0.26 ELF)  : RedHat Linux 6.1

  PostgreSQL version (example: PostgreSQL-6.5.1):   PostgreSQL-7.0.2

  Compiler used (example:  gcc 2.8.0)           : gcc egcs-2.91.66

=20
Select version() =3D PostgreSQL 7.0.2 on i686-pc-linux-gnu, compiled by gcc=
 egcs-2.91.66


Please enter a FULL description of your problem:
------------------------------------------------

When doing a large query from either an OpenACS 3.2.2 web page (/intranet/e=
mployees/admin/index.tcl) or from psql, I get the following error:=20
NOTICE:  PortalHeapMemoryFree: 0x0x41a37610 not in alloc set!
NOTICE:  PortalHeapMemoryFree: 0x0x41a37cc8 not in alloc set!
NOTICE:  PortalHeapMemoryFree: 0x0x41a37ca0 not in alloc set!
ERROR:  btree scan list trashed; can't find 0x0x41a37bf0


The PostgreSQL.org doxlist faq says the following...=20
5.2) What does the message "NOTICE:PortalHeapMemoryFree:=20
0x402251d0 not in alloc set!" mean?

You are pfree'ing something that was not palloc'ed.=20
Beware of mixing malloc/free and palloc/pfree.=20


...I'm not sure what to do with this information.

The postmaster process looks like so=20
  PID TTY      STAT   TIME COMMAND
  476 ?        S      0:04 /usr/local/pgsql/bin/postmaster -B 1000 -S -o -S=
 8000 -D/usr/local/pgsql/data
Other inserts and queries can be run in this and other databases through ps=
ql or from other OpenACS web pages.
Thanks for your help.=20

The troublesome query (either half of the union can be run successfully):=
=20
select users.user_id , coalesce(info.salary, 0) as salary,=20
users.last_name || ', ' || users.first_names as name,
                info.supervisor_id, info.years_experience as=20
n_years_experience, info.salary_period, info.referred_by,
                to_char(info.start_date,'Mon DD, YYYY') as=20
start_date_pretty,
                (case when info.project_lead_p =3D 't'=20
then 'Yes'::varchar else 'No'::varchar end) as project_lead,
                (case when info.team_leader_p =3D 't'=20
then 'Yes'::varchar else 'No'::varchar end) as team_lead,
                (case when supervisor_id is NULL=20
then 'missing'
                 else (select s.first_names || ' ' || s.last_name=20
from users s where s.user_id=3Dsupervisor_id) end) as supervisor_name,
                (case when info.referred_by is NULL=20
then 'nobody'
                 else (select r.first_names || ' ' || r.last_name=20
from users r where r.user_id=3Dreferred_by) end) as referral_name
           from users_active users, im_employee_info info,=20
user_group_map ugm
          where users.user_id =3D ugm.user_id
            and ugm.group_id =3D 8
            and users.user_id =3D info.user_id
union
select users.user_id , 0 as salary, users.last_name || ', ' ||=20
users.first_names as name,
                '' as supervisor_id, '' as n_years_experience, '' as=20
salary_period, '' as referred_by,
                '' as start_date_pretty,
                'No'::varchar as project_lead,
                'No'::varchar as team_lead,
                'missing' as supervisor_name,
                'nobody' as referral_name
           from users_active users, user_group_map ugm
          where users.user_id =3D ugm.user_id
            and ugm.group_id =3D 8
            and not exists (select 1 from im_employee_info
                            where user_id =3D users.user_id)
       order by upper(users.last_name),upper(users.first_names)





=20

Please describe a way to repeat the problem.   Please try to provide a
concise reproducible example, if at all possible:
----------------------------------------------------------------------

=20

=20

If you know how this problem might be fixed, list the solution below:
---------------------------------------------------------------------

=20

Re: Fw: PortalHeapMemoryFree error in OpenACS

From
Tom Lane
Date:
"Brian Mueller" <brian@twotomatoes.com> writes:
> When doing a large query from either an OpenACS 3.2.2 web page (/intranet/e=
> mployees/admin/index.tcl) or from psql, I get the following error:=20
> NOTICE:  PortalHeapMemoryFree: 0x0x41a37610 not in alloc set!
> NOTICE:  PortalHeapMemoryFree: 0x0x41a37cc8 not in alloc set!
> NOTICE:  PortalHeapMemoryFree: 0x0x41a37ca0 not in alloc set!
> ERROR:  btree scan list trashed; can't find 0x0x41a37bf0

Interesting.  However, I can't get excited about having to
reverse-engineer your database before I can try to duplicate the
problem.  How about a schema dump (pg_dump -s)?  Also, what query
plan is shown by EXPLAIN for the problem query?

            regards, tom lane

Re: Fw: PortalHeapMemoryFree error in OpenACS

From
Tom Lane
Date:
"Brian Mueller" <brian@twotomatoes.com> writes:
> When doing a large query from either an OpenACS 3.2.2 web page (/intranet/e=
> mployees/admin/index.tcl) or from psql, I get the following error:
> NOTICE:  PortalHeapMemoryFree: 0x0x41a37610 not in alloc set!
> NOTICE:  PortalHeapMemoryFree: 0x0x41a37cc8 not in alloc set!
> NOTICE:  PortalHeapMemoryFree: 0x0x41a37ca0 not in alloc set!
> ERROR:  btree scan list trashed; can't find 0x0x41a37bf0

Brian, it looks like this problem has already been fixed in current CVS
sources --- it's a foulup in subplan handling for APPEND plans, which
basically means that you need sub-SELECTS in a UNION to cause it.

Easiest patch for 7.0.* is to grab src/backend/optimizer/plan/setrefs.c
out of the CVS server or a recent nightly snapshot tarball and drop it
into 7.0.* sources as-is.

            regards, tom lane