今天改的版本，突然间陷入 while loop 无法中止 强迫中止时错误讯息是 File "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/ threading.py", line 1388, in _shutdown lock.acquire() 这种讯息有和没有差不多 有 lock 没有释放？ 於是我写了个 MyLock 取代 threading.Lock 开始记录到底是哪个 Lock 有进入而没有退出 全都有退出！根本查不到 最後是透过 git 不断卷回旧版，找到十二小时前的版本还可以正常退出程式 一查，重点不在程式，在资料！ 某一种资料格式，我会启动 Timer, 而 Timer 时间到後，我会再重启 Timer (其实就是连续脉冲波，每隔几秒一次的意思) 因为我预约了下一次的执行需求，所以程式无法释放 只要 cancel timer, 就解掉这个 bug 了 (bug 是一直存在的，只是一直没键入这种资料凸显 bug) 还真是忘了，在 Python 的 Timer 是以 Thread 来实现 而骨子里可能设了个 lock 那我问题来了：这次是幸运在 git 里保存够多细节，且能卷回一定能释放的旧版 假设没这样的环境，只能靠我自己抓，而错误讯息又只说有 lock 没释放 我能回溯知道是哪一行程式产生的 lock 锁住了吗？ 有什麽参数，什麽 debug tool 能用吗？ 谢谢 --

※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 116.241.233.114 (台湾) ※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Python/M.1680299059.A.BEA.html RLock 是允许重复进入，避免同一个 thread 自己把自己卡住 而我的要求是回应卡住的物件是在哪行指令生成 举例来说 Line 10: a = new C1() # test.c 这是产生物件；目前都有自动释放，但假如在没自动释放的 C 语言 而且我没有释放物件，造成记忆体浪费， 有工具能回应我，浪费的记忆体在 test.c/Line 10 吗？ 我还真用过这种工具 哇！我试试！ 谢谢 ... 超过我的程度 XD 装了，跑不起来.. ※ 编辑: HuangJC (116.241.233.114 台湾), 04/01/2023 15:21:44 当年我用过 debug tool 抓记忆体漏洞之类，真的过瘾 但有种很怪的感觉，那是高手在替我做事，而且能力是有限的 比如找寻未释放记忆体的原理是什麽？ a = new C1() // 配发记忆体 a del a // 释回 a 如果 a 忘记释放，要怎麽找出 a 在哪一行配发的？ 毕竟 a 这个符号可能被重覆配发，也可能 b = a // 被 b 承接走 a = NULL // 弃用 a 这个符号，但 b 忘了释放 XD 因此这种 tool 能做的只有。。当初 a 配发时，就把 debug info 顺便存入 比如覆写 new 这功能，成为 DEBUG_NEW 然後隐性的传入程式的资讯（利用 __FILE__, __LINE__ 这种 compiler 维护的符号） 这也代表配发记忆体时，我本来只配几个 byte, 但可能同时配发更多的 debug byte 因此 debug 时的速度会变慢，耗用记忆体会增加 但高手替我抓还是很好用 XD 等我程式写太大时，这种 tool 因为要多耗用很多 debug 资源，就会跑不动 最佳方案仍然是自己写 debug tool 但我如果功力高到会写 debug tool，我当初就不会犯错了！ 先有鸡还是先有蛋的问题 -------- 总之我这次学到了，Timer 元件其实要注意它的配发和释放 ※ 编辑: HuangJC (123.204.157.162 台湾), 04/06/2023 01:08:28 是遇到了才知道遇到了啊.. 我一开始可超级谨慎的 class MyApp(App): def f1(self): self.destroy() app = MyApp() pApp = weakref.proxy(app) btn = PushButton(app, command=pApp.f1) app.display() 比如我曾这样写程式，其中 pApp 根本没必要 为什麽这样写？因为我怕 btn 物件里如果保有 app 因为参考到自己，会导致永不释放 所以凡参考我都只留 weak 版本 後来我发现不这麽写，照样不会卡，照样释放，想法可以很单纯 XD 我从完全没有 gc 的 C 语言学起的，从前记忆体管理都自己来 那时如果释放了不把变数标成 null, 再叫用到就 null access 能碰到的问题可非常多 a = new C1(); b = a; // 比如进入函式，也是拷走一个 a 指标在函式里用 del b； // 除非我不在函式里释放物件，否则当然会写这种东西 a.xxx // 这时外面还想取用 a pointer 就惨了，null access 後来开始用有 gc 的语言，可是参照次数很重要 如果还有任何指标参照到物件，物件就不会释放 那循环参照怎麽算？还真是测了才知道 一般不会遇到？不是，我一开始学时曾经有遇到，但不知道就写了两年 举例来说，树莓派一开机就跑我的程式，但从没想过要关机 执行完毕直接断电，就算程式无法释放，都断电了是有何差别？ 只有刻意去想，我就是要让程式释放，才会测试到这件事 比如我可能要写远端更新，要让程式结束并且重开机 喔，还是有很暴力的写法，比如下个 kill process 指令 在程式未能退出的情况下，由 os 端杀掉 XD 会去注意是洁癖吧.. 总觉得，类似档案没有 close 等循序退出问题，如果没做，很不舒服 别人没遇到吗？ 比如我在写 ios 手机时，用的是 obj c 我也下载过别人的函式库用 我看别人防这个也防得很严 一堆 weaf ref 在用 应该说，为什麽 python 在参照到自己的指标留着时还能释放 这才是超乎我预期的 XD 所以 Timer 在几秒後才要启动，而它启动时要用到的指标要不要 weak 版？ 程式想退出了，几秒後根本就不存在，若保留指标程式就无法退出 那按键按了要退出程式，按键的程式里保留指标，为什麽可以退出 :P 那也是测了才知道。。 QA 不会做这项测试，都专注在跑程式，而不是退出程式 XD 我也是哪天心血来潮才测到的。 那时曾经呼叫同事写的副程式，用 try-catch 包起来呼叫 甚至是每次呼叫前才 load library (本来可以用静态写的，不必这麽麻烦） 呼叫後就 free library 为什麽要这样做？因为同事记忆体释放没写好啊，我整个 free 掉才会乾净 所以一般是没遇到，还是没注意到？ ※ 编辑: HuangJC (123.204.157.162 台湾), 04/07/2023 01:00:44 甚至我想过一个问题：参照到自己，或说交互参照 这种还有法子释放资源是怎麽做的？ （同事是说有很多论文，不过我不擅长查） 如果说这机制有 bug 会不会我刚用没问题，但用多了，资源就变无法释放？ 那这不是我有问题，是写释放的有 bug, 没确实 implement 出来 看过是说 gc 不会时时刻刻，而是久久做一次 所以我以前去主动检查有没有释放，也常没释放 必需在主动检查前，先主动催 gc 做一次垃圾搜集 会不会就是因为这样，我下载的第三方函式库才广用 weak 版本？ a 我 id 其实没帮助 我直说好了，有人说我半桶水 那我能怎样？膨风说自己全都懂？ 前不久和另一位也是资深工程师聊这边的状况 聊到有人叫我去读 os，他直接回我，他也从业几十年，但从没读过 os 所以我们只能这麽说：底线就是，这本来就是我的责任 资讯不够，多少是因为我不能把公司产品全丢到网路上，source code 公开 所以得用各种抽象的方式，只曝露一些点来讨论 若实在是不行也就算了 这我知道，知道还这麽做，就代表混入 debug 等心得.. 当年写 c，写到某个地方，我说怀疑 compiler 有 bug 也是被人狠狠嘲笑 几年後看到脸书上另一个朋友说，c compiler 有一大堆 bug... 咦，原来也有别人遇到，那我被笑又怎麽回事；只能说有没有人同样见识到了 责任不能推到 compiler 去，但我们得去验证这些问题存不存在 所以对这些都是有限信任 obj c 也是有 gc 的 （应该说随着年代， 很多语言的特性互相学习） 而它若是自我参照时，就不会释放！ 这我能写一个极小的程式验证到 发生时，就要'打破这个环节' 在 obj c 我也不会去 del, 我是把指标设为 None 这样循环参照就打破了 （我这篇里用到 del, 但那是 c 啊，先还原到最原始，没有 gc 的环境描述问题） 去说明这些我知道似乎也没有意义 知道我也是碰到这些 bug 了 Timer 是一种 Thread 这我知道 我不知道的是我启动了 lock lock 一般来说，是 multi-thread 时， 某 thread 要求独占资源，其它 thread 不能进入 而我使用 Timer 时，我没要独占什麽，所以我没想到它启动了 lock 或者，这问题不是 Timer 启动了 lock 我程式中本来就用了很多 lock, 凭最後出现的错误讯息，我并不知是哪个 lock 未释放 不然改个说法：我能不能把每个 lock 命名 当程式用强迫退出的方式并且收到错误讯息 能够知道是哪个 lock 没有释放 ※ 编辑: HuangJC (116.241.233.114 台湾), 04/08/2023 16:24:15 蛮常 hack 的，但还是不行，主要是猜测行为都猜错了，就无法看着 code 想像 来看这麽短的程式就好 from guizero import App, PushButton app = App() btn = PushButton(app, command=app.destroy) app.display() 这程式的目的只有一个：产生一个按键，按了就退出程式 我本来以为这不会正常运作的 理由是 btn 是个物件，它里面有变数参照了 app.destroy 那这样 app 的 ref count 不是会加一吗？ 不用执行，光有变数拷走我的指标，就要加一了，没错吧.. 不然万一要执行时 app 不存在怎麽办？ 按下按键，我以为程式要卡死不能退出，但它就是顺利退出了 我就是以为，这个 gc 可以自行解决啊？ 结果 timer 的倒没自行解决，得由我来 cancel timer! ※ 编辑: HuangJC (116.241.233.114 台湾), 04/09/2023 13:21:02 要讲这麽笼统的话，建议计概重学，建议 python 重学，不也都说得通？ 成语 邯郸学步 就这意思了 学着学着有没有更高明？还是反而被搞糊涂了呢？ thread 就我所知，就是系统把目前所有的暂存器通通储存起来， 然後切换到另一个 thread 的 context 去 之後再切换回来，除了时间点改变之外，CPU 完全可以在这个点继续往下执行 而两个 thread 如果有共用变数，且抢着修改，可能混成一团 因此在有必要独占一个变数时，就可以用一个同步物件来 lock 使用权 当然随着应用的方式不同，看起来也许不像锁着物件，而像锁着程式区块 比如 critical section 的应用方式 知道，但解决不了 因为在这个地方忽略而产生 bug, 错讯讯息不见得是在这个地方 所以我是在请教 debug 技巧 就以我文章最前面所讲的问题，我是已经解决了 我是知道解法，再回头看错误讯息，觉得没有帮助 其实我想要的是在程式强硬退出後，有'列举所有 thread 状态'这类指令 所以我已经在打造自己的 debug tool 了 希望可以追踪 thread 当下的行为，以知道 thread 为何释放不了 ※ 编辑: HuangJC (49.217.174.143 台湾), 04/10/2023 01:51:25 淌浑水都是自愿的，而且都不是简单的工程 你说马蜂窝又怎样呢？ 在针对微软出的一本比一般砖块还大的经典书籍，教人 debug 时 就有介绍到自己打造 debug 工具 差别是时代进步後，会有人直接准备好这个工具给你 埋设本身就是一堆 code，如果这种 code 重覆用，就值得打造一个工具 所以你其实不能反驳我的做法 最单纯的 log, 类似 echo abc >> myApp.log 但复杂的也是 import logging，有人打造好了不是？ 以分配记忆体的 new 指令来说 a = new C1(); 改成 a= DEBUG_NEW c1(); 这样的思维逻辑，不是我想出来的，是经典书籍上有的 你可以说现在时代进步，这招太旧 但这招真的不是我想的。 那我也只能说谢谢了 不管你说要学多少东西，谦虚的人绝不会说那是错的 作业系统我不会不懂，但要说哪一块挂万漏一恰好不熟，当然有可能 如果我比你高明，我说你作业系统不熟该重学 想必你也不会拒绝 问题在能不能点出章节，不然是不是要投入好几个月甚至几年？ 这是同一回事，我的除错工具，主要工作就是在埋日志 步进执行我有用喔.. 有用我还是解不了这个问题 我不是说了嘛，我是 bug 已经解了，回头看错误讯息，觉得错误讯息没帮助 我可以把程式写个很精简的小范例重现 bug 但我还是不懂那和 OS 的关系在哪 何谓 thread? 那我乾脆就默了一段出来 以此代表在 OS 我也是了解这段的（而其他段或许不了解） 既然要说我对 OS 了解不够 那是不是也默一段出来，说说我哪里错了？ 不见得会 C 再熟，看别人程式也会需要重新熟悉 又不是别人程式用 C 写的，而我写 C 久了，我就一定能看懂 如果你是一定能看懂别人程式，其实你很优秀 :P 老实说我很久没碰 C 了，但对 C 的语法一直是还在参考 因为一堆语言是 c like 啊，C 应该算我的基础 gc, 垃圾搜集，c 没有吗？ （啊，还真难一点，改说 c++ 好了） 在建构，解构式里，埋 reference count 这些 其实也是慢慢发展出来的 更别说同样是 c, 换了一套 ide, 结果环境不熟 但基本就是一样，step, trace into.. 所以从 python 的直译器去，会很快见到问题？ 这想法有点怪，有点在 python 解不了，去找外挂的感觉 就好像 c 看程式解不了，去找执行档反组译成组合语言解的感觉 然後如果我说我组合语言写十几年 你回呛说那当然可以直接看组合语言 啊。。组合语言是懂，但可读性是那样子 不在高阶语言的高度直接解，不嫌辛苦？ 我承认有个时候会需要进组合语言解： 怀疑 c compiler 本身有 bug，要看它做错什麽时 但如果信任 c compiler, 这事我就不干了... ※ 编辑: HuangJC (123.204.157.211 台湾), 05/04/2023 03:40:36 我学习能力差一样不用你关心啊 我是什麽重要的人影响到你了吗？ 难道我说你学习能力很好，你能接受？ 你没这麽自大吧。。。 对我来说，我的重点只有'这个我不会' 其他不重要，也没那麽自大 我相信我有多谦虚，你也有 ※ 编辑: HuangJC (123.241.134.39 台湾), 12/01/2023 21:09:11