Bagnon

Bagnon

122M Downloads

Bagnon+Pawn go into endless loop in Item:UpdateUpgradeIcon() for some items

rowaasr13 opened this issue ยท 1 comments

commented

Running Software (issues missing this information will be deleted):

  • Addon version: 9.0.4 (+ Pawn version 2.4.10)

Describe the bug

  • Opening Bagnon inventory with any of the items listed in screenshot with Pawn installed causes Bagnon to go into endless loop of updating their "upgrade" status, which causes Pawn to eat up tons of memory

To Reproduce
Steps to reproduce the behaviour:

  1. Make sure Pawn is installed as well.
  2. Get yourself any of the listed item. (will likely work with any other similar equipable item without stats)
  3. Open Bagnon inventory
  4. Watch Pawn memory usage rate go up in progression every 0.5 seconds in your favorite performance tracking addon (rate of growth is Pawn problem, but Bagnon triggers it)

Expected behaviour
No endless loop and huge memory consumption.

Screenshots
Screenshot with names of some items affected, stack trace and some instrumentation added to Pawn code that will be described below.
WoWScrnShot_011121_141639

Additional context
Instrumentation used:
Addons\Pawn\Pawn.lua line 387 changed to:
PawnIsContainerItemAnUpgrade = function(bagID, slot, ...) print('line 387', GetTime())
line 389 changed to:
local _, Count, _, _, _, _, ItemLink = GetContainerItemInfo(bagID, slot) print(ItemLink) assert(not GiveMeStack, "stack given!")

After that, I've opened inventory, watched endless roll of same 4 items you see on screenshot, typed /run GiveMeStack=1 and traced issue to Bagnon through stack. Apparently PawnIsContainerItemAnUpgrade always returns nil for those items and Item:UpdateUpgradeIcon() repeats attempts to check their state forever.

commented

(I'm the author of Pawn)

Based on this description it definitely sounds like there are some times PawnIsContainerItemAnUpgrade is returning nil when it could be definitively returning false. I've added an issue to look into that! (I'm currently tracking my to-dos on Azure DevOps so I don't have a public link to share, but it's issue 106 which is a totally believable and not-made-up-sounding number.)