Many log entries after adding google calender

ℹ️ Support
,
1

My logs are (not so) slowly filling with errors since one of my users added a google calendar.

The warnings show it occuring on line 560 of apps/dav/lib/DAV/CustomPropertiesBackend.php

The errors look suspiciously like the same problem at:

Is there a known fix for this? The bug above was reported in April 2023

2

I see no logs in here.

1 Like
3

If the log webapp didnt hang my computer it’d help. But You have the relevant line number, and a report of a similar bug.

I’ve read the code, and even though I’m not intimately familiar with the codebase, even I can see that it’s very likely to be the same bug (but possibly in a different part of the code to the one reported).

I’m sick of people discarding bug reports just because there isn’t a screed with it. I’m an ex kernel dev, and such comments are simply lazy. Anyone familiar with the codebase with half a brain should be able to work out the problem here.

When did programmers get too stupid to debug things without a log?

Here’s one of thousands of log entries extracted from the nextcloud log file:

{“reqId”:“blah”,“level”:3,“time”:“2024-11-23T12:00:58+00:00”,“remoteAddr”:“1.2.3.4”,“user”:“nooneyouknow”,“app”:“PHP”,“method”:“PROPFIND”,“url”:“/remote.php/dav/calendars/username/”,“message”:“unserialize(): Error at offset 61 of 64 bytes at /var/www/nextcloud/apps/dav/lib/DAV/CustomPropertiesBackend.php#560”,“userAgent”:“Mozilla/5.0 (X11; Linux x86_64; rv:132.0) Gecko/20100101 Firefox/132.0”,“version”:“30.0.2.2”,“data”:{“app”:“PHP”}}

4

Oh, I’m not a programmer. I’m just pointing out you didn’t upload any logs despite complaining about “logs filling with errors” which could be used to help pinpoint the bug.

Anyway, did you open a GitHub issue?

5

If he says the logs are very similar and it might be the same issue, then he could just add on github that he is still seeing the issue in NC 30.

Unfortunately, the status is not really clear. It is obviously not fixed, not clear if they have problems reproducing the problem, or if has just very low priority.

There was a hint about the some database entries: DAV properties propertyvalue column has wrong column type · Issue #37754 · nextcloud/server · GitHub that might create the issue.

6

It really shouldn’t need reproducing. If the DB field cannot accept the data type being put in it, and the code (serialize()) is putting that type of data in it, it is a bug.

No logs needed. Just like you wouldn’t need a log to tell why a float->int->float conversion in C wouldn’t yield the same output as input.

Not every bug requires a log to understand or debug - static analysis is still a thing in 2024.

Someone simply needs to look at line 560 in that file, look at the database, and fix the incongruity, either by using the right data type in the DB (yes please), or by encoding the output of serialise() into something the DB can actually handle (ugh).

This should take a core nextcloud dev moments to fix, but it’s been open since April 2023. What the hell is going on at NC HQ?! This should be child’s play.

(I’m not even particularly fluent in PHP - my main languages are C and various RISC assembly languages, but I can clearly spot that the poster on github was spot on in their assessment of the other very similar bug.)

It’s probably endemic in the codebase - I’d hazard a guess that serialize() is used quite a bit… Lets see…

find apps/ core/ -type f | grep \.php$ | xargs grep serialize | wc -l
1124

Yep, very common indeed. Now I doubt every instance is problematic, so probably this one is a leftover from some cleanup or other silly mistake - it happens.

Where are the actual NC devs? they obviously never bothered to fix the one in github, so I see very little point in reporting it again - this isnt one of those “only happens occasionally to a handful of users” bugs - it’s a blatently obvious mistake with what seems to be a fairly trivial fix.

With gaping holes like this in the codebase, who here thinks that NC is likely to actually be “secure” ?

NOT confidence inspiring. I hope potential buyers of the “Enterprise” version read this.

7

You seem to be able to troubleshoot and fix this. Why dont you do so and submit your fix on github?

Thanks for contributing.

2 Likes
8

There is a big gap between doing some basic checks and getting a fix into the code.

  1. I’m not a PHP dev - I don’t have time to learn the language, which would be necessary to be sure my fix was appropriate. Just because any decent programmer can READ any language, doesn’t mean they are aware of all the subtleties.

  2. I don’t want a github account. It’s owned and operated by Microsoft, an American corporation, and I want nothing to do with them. I certainly don’t trust them with my data.

  3. I shouldn’t need to - I’ve provided ample information to any competent NC dev to fix this (I’ve really only confirmed that the same old bug that someone else has already given an explanation of (on github too!) is still present). This should be a 5 minute fix for a nextcloud core team dev. Where are they?

(Reminder - the other bug remains unfixed since April 2023)

9

Not here. This is a community forum.

The developers mainly hang out in the github :wink:

1 Like
11

Sorry, I didn’t go through all in detail. Just if you were in doubt that it is the same problem or not. If github issues represent a bit more feedback, developers can see if only one person is affected (that might have done something “differently”) or if this bug just hits anybody and is not a very special use case.
At least, this is some use case/environment, they don’t automatically test for…