Solved: Can the Bug ID: CSCek64188 be resolved in 15.0(1)M9?

Rojer-bkk · ‎10-03-2012

Hi,

I got the router hung state (cannot telnet or console) and got the MALLOCFAIL error message on the router 3900 with 15.0(1)M5. I was suspected the bug CSCek64188. Please help me to confirm the Bug can be resolved in 15.0(1)M9? Thanks in advance.

David White · ‎10-03-2012

Rob,

You don't see it in the Fixed-in field, as the bug was not directly fixed in 15.0(1)M train. Instead, it was vixed via merges from 12.4 --> 12.4T --> 15.0M, but it is fixed in 15.0(1)M (and all later images in that branch).

Sincerely,

David.

View solution in original post

David White · ‎10-03-2012

The problem is the Fixed-in is "stamped" at the time the bug commits are directly added to a train. If that train is later the parent of a future train or other branches happen, then the Fixed-in field does not get "re-stamped".

One way to think about it is when a bug is fixed, it will get applied to all active trains which exist at the time and will most likely be directly commited or waterfalled. However, assume a year from now that a new train is created from one of the already patched trains, should the Fixed-in field be populated for the new train? And would we need to do that for all bugs fixed before the new train was created. Similar (but more complicated) issues arise from various types of merges, syncs, etc.

For this particular bug, I see it is fixed in over 21,000 images. Listing all of those would be unreadable :-)

However, the main point you raise is one we are aware of and trying to find a good solution to. Which is provide an 'easy' way for customer to determine whether the version they are running is affected by a given bug. We need to move to more automation to accomplish this, but I believe it is doable. Until then, please ask away if you are unsure - as we continue to try to improve the tools.

Thanks again,

David.

View solution in original post

Rob Huffman · ‎10-03-2012

Hi Rojer,

I don't believe so

Here are the "Fixed-In" versions;

Fixed in: (40)

15.1(2)STV11.1,15.1(2)SG1.90,15.1(1)SG5.83.1

15.1(1)SG5.64,15.1(1)SG5.63,15.1(1)SG15.3

15.0(4.4)DPB1,15.0(2.26)DPB1.47,12.4(9)T3

12.4(8d)M,12.4(24.5.2)PIC1,12.4(22.3.4)PIC1

12.4(12a)M,12.4(12.12)T,12.4(12.10)M,12.4(11)T1

12.4(10b)M,12.3(7)XI10a,12.3(21.11)M

12.2(53.16)SIM,12.2(52)EY,12.2(50)SY,12.2(49.90)SQ

12.2(47.1)S,12.2(33)SXH,12.2(33)SRC,12.2(33)SB

12.2(32.8.99a)SR133,12.2(32.8.39)SRB

12.2(32.8.11)SX37,12.2(32.8.1)YCA206.18

12.2(32.8.1)YCA172.24,12.2(28)SB7

12.2(18.7.11)SXF,12.2(18)ZYA3c,12.2(18)ZY1

12.2(18)SXF8,12.0(32.2)S4,12.0(32.11.1)SY

12.0(32)SY4

And here are the release notes that include 15.0(1)M9 where this bug is NOT

shown in the

Resolved Caveats—Cisco IOS Release 15.0(1)M9

http://www.cisco.com/en/US/docs/ios/15_0/release/notes/150MCAVS.html#wp1075319

Cheers!

Rob

"May your heart always be joyful
May your song always be sung" - Bob Dylan

David White · ‎10-03-2012

Rob,

You don't see it in the Fixed-in field, as the bug was not directly fixed in 15.0(1)M train. Instead, it was vixed via merges from 12.4 --> 12.4T --> 15.0M, but it is fixed in 15.0(1)M (and all later images in that branch).

Sincerely,

David.

David White · ‎10-03-2012

Yes, CSCek64188 is fixed in 15.0(1)M9.

However - it is also fixed in 15.0(1)M5. Therefore if you are running 15.0(1)M5, then I would say you are not experiencing this bug.

Sincerely,

David

Rob Huffman · ‎10-03-2012

Hi David,

Thanks for clearing this up my friend +5

I'm always slightly confused as to why the "Fixed-In" doesn't show

all the "Fixed-In" versions as this omission just leads to more of these type of

queries.

But it's probably just me being confused

Cheers!

Rob

"May your heart always be joyful
May your song always be sung" - Bob Dylan

David White · ‎10-03-2012

The problem is the Fixed-in is "stamped" at the time the bug commits are directly added to a train. If that train is later the parent of a future train or other branches happen, then the Fixed-in field does not get "re-stamped".

One way to think about it is when a bug is fixed, it will get applied to all active trains which exist at the time and will most likely be directly commited or waterfalled. However, assume a year from now that a new train is created from one of the already patched trains, should the Fixed-in field be populated for the new train? And would we need to do that for all bugs fixed before the new train was created. Similar (but more complicated) issues arise from various types of merges, syncs, etc.

For this particular bug, I see it is fixed in over 21,000 images. Listing all of those would be unreadable :-)

However, the main point you raise is one we are aware of and trying to find a good solution to. Which is provide an 'easy' way for customer to determine whether the version they are running is affected by a given bug. We need to move to more automation to accomplish this, but I believe it is doable. Until then, please ask away if you are unsure - as we continue to try to improve the tools.

Thanks again,

David.

Rob Huffman · ‎10-03-2012

Hi David,

Your explanation makes perfect sense. I don't think listing 21,000

"Fixed-In" images is at all feasible

But the other point you make is the most salient one here;

"provide an 'easy' way for customer to determine whether the version they are running is affected by a given bug."

People @ Cisco understand "stamped, committed, waterfalled, parent train" etc. etc.

but peeps like me may not understand the whole bug fix hierarchy. The fact that smart

people like you and all the great people at the Online Tools can see the disparity here

and are working at simplifying the process is good enough for me

Anybody who has ever been bitten by a bug that they assumed would be fixed in a

newer version will understand what I mean. (I know....never assume)

Thanks again!

Cheers!

Rob

"May your heart always be joyful
May your song always be sung" - Bob Dylan