On Thu, 10 Mar 2005, Niklas Edmundsson wrote:
I enabled kernel memory debugging (bosdebug -M ; bosboot -a ; reboot) in order to try to further pinpoint the problem, and these are my findings:
* Going back to an unpatched 1.3.78 it dumps with the xmalloc debug message "A program has tried to access freed xmalloc memory". In both cases the crash occurs after having obtained an AFS token and then trying to access AFS using that token. The "kdb stat" output from the dumps are at the bottom of this post.
Does this give a hint on what's wrong? I'm wading through the source at random not finding anything obvious. All those #ifdefs makes the thing rather hard to read :/
I had a closer look att the #ifdef-swamp starting at rxi_Alloc() and noted that quite a lot of code is only used on AIX and older HPUX-versions. I took a large axe and removed quite a lot of "this is only used on AIX/HPUX"-code and now the thing seems to work regarding the kernel module. I'll get back to you with patches when I've done some more testing. My test-box seems to survive with MAXKTCTICKETLEN 12000 now, and that's a rather good sign.
In general, there seems to be a large confusion regarding where&when to do locking and where in the code to add OS-related compatibility. I believe that all compatibility crud should be in the "leaves" of the source code tree, but in OpenAFS there are #ifdefs everywhere making it hard to actually read the code... Am I right in assuming that the "throw in a lock here to make it work on architecture X"-ifdefs are a remnant of the old Transarc-days?
Is there some effort to clean up this mess, or can we expect more of "architecture X starts to mysterously fail due to code-fork by #ifdef" in the future?
/Nikke
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Niklas Edmundsson, Admin @ {acc,hpc2n}.umu.se | [EMAIL PROTECTED]
---------------------------------------------------------------------------
Eat yogurt and get cultured
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
_______________________________________________
OpenAFS-devel mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-devel
