Strange bug in 10.2.0 involving merging rows from one table into another

I have a table with about 180,000 rows and 50 columns, and another table which has an identical structure but is empty. The source table has no indexes or constraints; the destination table has a primary key that is a combination of varchar2 and number columns. When I do the following:

insert into dest_table (column_z, column_1, column_2,...) select COUNT(*), column_1, column_2,..., column_N, SUM(column_a), MIN(column_b), MAX(column_c),... from source_table
group by column_1, column_2,...,column_N

I would expect that SUM(dest_table.column_z) would equal COUNT(source_table.*), but they are off by about 40 rows - in other words, 40 rows in source_table are not being included in the select. The strange thing is, all of the rows in source_table are included if:
(a) the insert is done on a 8.1.7 database (instead of 10.2.0);
(b) I add "order by column_1, column_2" to the end of the insert
statement;
(c) I do just the select without the insert.
Also, when I created a copy of source_table (using the same extent sizes as the original, although on another tablespace) and did the insert using that data, the number of ignored rows was different.

Is this a known bug? Has anybody else come across anything remotely like this?

• Don