Weird bug in MSL implementation of alloc.c

Weird bug in MSL implementation of alloc.c

Post by raphael ding » Sat, 16 Nov 2002 19:04:50



Hi,

General Description :
---------------------
I have a weird bug in MSL implementation of var pools alloc (CW 7.2).
I use a std::deque <SharedPtr::SomeInterface>
where SharedPtr is an implementation of a kind of shared ptr type class
and SomeInterface is an abstract class.
The bug appears while trying to make a push_back on that deque.

I use that in our private libs, that has always worked with various
product on various platforms (92 products on mac, 3 platforms). For 2
products from our products range, the bug appears on carbon version (MSL_
All_Carbon.lib), running MacOSX.
Note that I'm not saying that this is an MSL bug.

Detailled Description :
-----------------------
while making a push_back on that deque, it tries to alloc some memory
from the pool using placement new, and the call finally ends up in Block_
subBlock (alloc.c revision 1.37.4.1).

for some reason (this is the bug in fact), after the call st = Block_
start (ths) (line 803), st->next_ is equal to 0 so line 815 fails (see
macro of SubBlock_size).

I would really be glad to have some help, since I'm not rich enough to
handle codewarrior support plan.

Thanks,

Raphael


 
 
 

Weird bug in MSL implementation of alloc.c

Post by Howard Hinnan » Sun, 17 Nov 2002 00:37:41



| Hi,
|
| General Description :
| ---------------------
| I have a weird bug in MSL implementation of var pools alloc (CW 7.2).
| I use a std::deque <SharedPtr::SomeInterface>
| where SharedPtr is an implementation of a kind of shared ptr type class
| and SomeInterface is an abstract class.
| The bug appears while trying to make a push_back on that deque.
|
| I use that in our private libs, that has always worked with various
| product on various platforms (92 products on mac, 3 platforms). For 2
| products from our products range, the bug appears on carbon version (MSL_
| All_Carbon.lib), running MacOSX.
| Note that I'm not saying that this is an MSL bug.
|
| Detailled Description :
| -----------------------
| while making a push_back on that deque, it tries to alloc some memory
| from the pool using placement new, and the call finally ends up in Block_
| subBlock (alloc.c revision 1.37.4.1).
|
| for some reason (this is the bug in fact), after the call st = Block_
| start (ths) (line 803), st->next_ is equal to 0 so line 815 fails (see
| macro of SubBlock_size).

I believe you have stumbled across a bug in the Pro 7 alloc.c.  It was
not discovered and fixed until the Pro 8 release (Pro 8 does not have
this bug).

To fix, open alloc.c:

In the function Block_subBlock, change these lines:

   st = Block_start(ths);
   if (st == 0)
      return 0;
   sb = st;

To:

   st = Block_start(ths);
   if (st == 0)
   {
      ths->max_size_ = 0;
      return 0;
   }
   sb = st;

(that is, insert the one extra statement under the if)

Recompile MSL C (and the runtime libs that encompass MSL C).  We
apologize for the inconvenience this bug has caused you.

--
Howard Hinnant
Metrowerks

 
 
 

Weird bug in MSL implementation of alloc.c

Post by raphael ding » Fri, 29 Nov 2002 01:04:40


Thanks !

Raphael

 
 
 

1. Weird weird weird problem with a wall switch...

Hi!

I have the following problem with the X10 Pro version of the WS467 (It appears to be the same switch only
the model number seems to be different).

I installed it on house code A unit 8 and initially it was working fine but it's now acting somewhat strangely...
It always processes A8 OFF but it almost never processes A8 ON. The only exception seems to be when I turn it
on locally and then turn it off with a Palmpad sometimes after that it either works for awhile or it continues
not to process commands (from the CM11A, a TM751 or a RR501).

I cleared the CM11A memory to be sure there wasn't anything weird programmed in it (I even tried unplugging it). The TM751
and RR501 are not on the same house codes. I tried changing the house code and unit number of the wall switch... Nothing
worked until I tried moving the TM751/RR501 in the same room or in a room adjacent to it...

It now seems to work... The only thing I don't understand is why the CM11A is now able to communicate with it since
it has ALWAYS BEEN in the same room...

The CM11A doesn't use RF to communicate, what's happening?

BTW, I don't seems to have the phase coupling problem or if I do it only affects that room because wherever I put
a module it works...

Help!

Thanks for any and all suggestions!

Nicolas Riendeau

PS: Please forgive my English, it's not my mother tongue.

2. Mirror technologies

3. realloc bug in MSL?

4. Discard hardware before?

5. Dev.ser and a weird RS-485 implementation

6. x-10 post to comp.binaries.apple2

7. Possible Bug in PGP 6.0 and Outlook/OE Plug-ins

8. ANN: The Convertible by RoadMate! now at PalmPilotGear H.Q.

9. Vuescan 7.6.24 LS4000 Raw file scanning- weird behavior- possible bug?

10. Weird Excel Bug

11. FS98 weird altitude bug over mountains !

12. weird situation, BUG or I'm not doing it right

13. Weird bug.