Can't call method "isa" on unblessed reference at ... amavisd

Hi Peter,

I'm running into the same problem. Did you have any luck in resolving this?

Many thanks,

René

I'm seeing this too.

This seems like it should be something obvious. Perl's not even close to my best language, but from what I can see an unblessed reference in the code should be a problem for many people. Hopefully someone who knows what's going on will see this soon.

I see that it's breaking in lookup2() which is looking for an email address in SQL/LDAP/hash map etc. I have a lot of aliases defined. Wonder whether that affects this. I don't know how heavily people are usingthe different table types...

Since it is an upgraded system, my gut feeling would be that it is an issue with amavisd.conf causing this.

Earlier versions looked up /etc/amavisd.conf, 10.8 should look up /Library/Server/Mail/Config/amavisd/amavisd.conf

Try and remove the one in /etc (make a backup first of course), restart amavisd and see what happens.

Also check that the old amavis instance in /usr/bin is not being called instead of the one in /Applications/Server.app/Contents/ServerRoot/usr/bin/amavisd

And that there is no launchd item in /System/Library/LaunchDaemons launching an old version.

I'll give that a shot. In another thread I mentioned that in lookup2 here:

for my $tb (!$tables_ref ? () : @$tables_ref) {

my $t = ref($tb) eq 'REF' ? $$tb : $tb; # allow one level of indirection

my $reft = ref($t);

$reft is a VSTRING, which isn't handled by the following code.

Would a bad entry for one of the *_maps parameters cause this?

Also, I do already know that the correct amavisd script is being called because I put some debug output into the one in /Applications/Server.app/Contents/ServerRoot/usr/bin/amavisd, and it worked.

Well, there's no other copy of amavisd.conf on the system. There's no other startup code for amavisd, just the proper version.

The entries in /Library/Logs/Mail/amavisd all look good as far as I can tell. The paths all point to the current places at least.

Sad that there's such poor information on what can go wrong with amavisd out there... The fact that it's not handling one of the types that can get passed in isn't good. I don't know enough Perl to narrow it down any more though.

Oh well. I guess I'll have to disable amavisd for the moment.

I took one last look, and saw that the 'upgraded' version of amavisd.conf had a value for $sa_tag2_level_deflt in the format 'X.Y.Z', instead of a simple decimal number.

The value in the original amavisd was correct, but the upgrade process is broken somehow.

Changing it back to an X.Y value appears to have fixed the problem.

This is consistent with the type value of VSTRING that I was seeing in my debug output.

Glad you got it sorted.

I ended up doing a clean install and everything is working now. Thank you all for your helpful comments.

Nice one Kevin