Blank page after login

Hello All,
I recently migrate our company’s self hosted Gitea Server from a NixOS server to a RHEL based operating system. With many ups and downs, I finally managed to migrate it and I thought I was successful. I thought that because with my Active Directory account which I was/am using to login to our previous server and also on the new one I did not notice anything wrong. However only my account and one of my colleague were able to successfully browse the whole server via the gui. However everyone else after they their successful login they get a blank page. If they manually type various urls paths like gitea.xxx.com/explore/repos or anything else they get the page successfully. Same goes if they just type their username. They can view their profile page.
The only difference between my account and my colleague’s account who’s working like mine is that we have very new account into hte old server. Everyone else account is 2 years old or older.
Some interesting findings on the log file of gitea are :

2022/04/14 16:38:20 routers/web/base.go:130:1() [E] PANIC: runtime error: invalid memory address or nil pointer dereference

or

2022/04/14 15:23:14 ...s/context/context.go:204:HTML() [D] Template: home
2022/04/14 15:23:16 ...s/context/context.go:204:HTML() [D] Template: user/auth/signin
2022/04/14 15:23:22 routers/web/base.go:130:1() [E] PANIC: runtime error: invalid memory address or nil pointer dereference

anything else is looking kind normal.

I do understand that I do not provide much info, however I am happy to provide any kind of log if you need more info.

Thank you very much.

1 Like

Please provide your Gitea’s version information.

Hello lunny,
Here are some more details:
The old Gitea server:
Gitea version: 1.9.6
Database: Postgres SQL 10
Operating system: NixOS

The new Gitea server:
Gitea version: 1.16.5
Database: Postgres SQL 14
Operating system: Rocky Linux 8.5

Let me know if you need me to provide you with configuration and any log file.(I have to hide sensitive information though)

Kind regards
Chris

Do you have any custom template files?

Hi @chrish,

2022/04/14 15:23:22 routers/web/base.go:130:1() [E] PANIC: runtime error: invalid memory address or nil pointer dereference

In Gitea 1.16.5 this Indicates that a 500 error was returned and you should have more information in the content returned. Could you share this (properly redacted) as well as the URL of the page?

However everyone else after they their successful login they get a blank page. If they manually type various urls paths like gitea.xxx.com/explore/repos or anything else they get the page successfully. Same goes if they just type their username. They can view their profile page.

Are they able to navigate successfully everywhere after they got the blank login page (the 500 error above presumably)? Or are they also having errors elsewhere?

The only difference between my account and my colleague’s account who’s working like mine is that we have very new account into the old server. Everyone else account is 2 years old or older.

This is likely because the information collected by Gitea from ActiveDirectory two years ago is missing “something” and your more recently created account has that “something”. It does not bother 1.9.6 but 1.16.5 is unhappy about it. The key to finding that “something” may be in the error page.

Cheers

I have only modified the home.tmpl and the head_navbar.tmpl.
On the home.tmpl, I took out all of the Gitea content and I just added our company’s logo, a welcome text and a sign in link. Everything else is default.
On the head_navbar.tmpl, I added the dashboard button. Company wants the Dashboard to exist, as a menu, despite that the logo does exactly the same thing.

Hello @dachary

Only if the type the correct url on top. For example https://gitea.domain.com/user1 can view their profile.
Or an other example is https://gitea.domain.com/explore/repos can browse all of our repos.

Unfortunately the do not get any error page. Even if we open a console(developer tools) inside their web browser and look for any errors, there are none.
The only error we got is from gitea logs.

An other test that we did was to create a new local (gitea) user and try to login and everything was alright. ( I know this is a bit pointless but we established that the issue exists only with all the old users ).

What could I provide to help you identify the issue? is there any way to upload files? Would you prefer pastebin? or just paste here any log file, configuration ?

1 Like

Did you tick persist log to avoid clearing them on page reload?

1 Like

I browsed release notes back to 1.9.6 to find things you might want to check and found those:

Not related to your issue but good to know.

Have you tried removing your customisation of the standard templates yet? I had some issues after the update to 1.16.x that were caused by custom templates.

1 Like

Hello all,
Before I continue I would like to thank you all for your time to help me with this issue.
So…

I tried it and thank you very mush for that tip. It help me a lot.

Yes I did something similar and I will explain later here.

So yesterday I did not post anything because I tried several troubleshooting things driven by your responses and also from googling suggestions.

I firstly cloned the host server so I could play safe. Then I remove from the folder $GITEA_WORK_DIR/custom/templates all the templates that I have put and modified I replaced home.tmpl with the original one and then the base/head_navbar.tmpl with its orginal too. That did not make any difference. Old users (local and active directory users) got the same blank page. My user which is an active directory user worked perfectly fine. Then I created a new local user and he worked fine too.
Later yesterday I saw the announcement of the newest Gitea release and I thought to give it a go. So I downloaded the binary, stop the gitea service, back(move) the old binary elsewhere, copy the new binary on /usr/local/bin/ folder and start the service. Something magical happened. Now the “problematic” users get a 500 error page.

That is a progress! Well we did not have that before. So I stopped the service and remove all the extracted templates (home.tmpl, base/head_navbar.tmpl) and left the folder completely empty. Restart the service and same issue.
The only working users (new users) are able to see the landing page.

I am thinking to start a new Gitea from scratch and just copy paste the repos to see if that works. But before I do that any other suggestions?

Kind regards

1 Like

Some additional output.
When I login the log file is showing this:

2022/04/22 16:30:19 ...s/context/context.go:204:HTML() [D] Template: home
2022/04/22 16:30:25 ...s/context/context.go:204:HTML() [D] Template: user/auth/signin
2022/04/22 16:30:33 ...s/context/context.go:204:HTML() [D] Template: user/dashboard/dashboard

For accounts that get the 500 error:

2022/04/22 16:32:22 ...s/context/context.go:204:HTML() [D] Template: home
2022/04/22 16:32:33 ...s/context/context.go:204:HTML() [D] Template: user/auth/signin
2022/04/22 16:32:41 routers/web/base.go:130:1() [E] PANIC: runtime error: invalid memory address or nil pointer dereference
        /usr/local/go/src/runtime/panic.go:220 (0x453075)
        /usr/local/go/src/runtime/signal_unix.go:818 (0x453045)
        /source/routers/web/feed/profile.go:37 (0x1fb2fdc)
        /source/routers/web/user/home.go:134 (0x1fc9b12)
        /source/routers/web/home.go:41 (0x202c110)
        /source/modules/web/route.go:74 (0x1e3fac4)
        /usr/local/go/src/net/http/server.go:2084 (0x7a3fee)
        /go/pkg/mod/github.com/go-chi/chi/v5@v5.0.7/mux.go:442 (0x164edd5)
        /usr/local/go/src/net/http/server.go:2084 (0x7a3fee)
        /source/modules/web/route.go:113 (0x1e402b1)
        /usr/local/go/src/net/http/server.go:2084 (0x7a3fee)
        /source/modules/web/route.go:113 (0x1e402b1)
        /usr/local/go/src/net/http/server.go:2084 (0x7a3fee)
        /source/modules/web/route.go:113 (0x1e402b1)
        /usr/local/go/src/net/http/server.go:2084 (0x7a3fee)
        /go/pkg/mod/github.com/go-chi/chi/v5@v5.0.7/middleware/get_head.go:37 (0x1e6fb64)
        /usr/local/go/src/net/http/server.go:2084 (0x7a3fee)
        /source/modules/web/route.go:113 (0x1e402b1)
        /usr/local/go/src/net/http/server.go:2084 (0x7a3fee)
        /source/modules/context/context.go:745 (0x1660786)
        /usr/local/go/src/net/http/server.go:2084 (0x7a3fee)
        /go/pkg/mod/github.com/go-chi/chi/v5@v5.0.7/mux.go:71 (0x164cc0c)
        /go/pkg/mod/github.com/go-chi/chi/v5@v5.0.7/mux.go:314 (0x164e5bb)
        /usr/local/go/src/net/http/server.go:2084 (0x7a3fee)
        /go/pkg/mod/github.com/go-chi/chi/v5@v5.0.7/mux.go:442 (0x164edd5)
        /usr/local/go/src/net/http/server.go:2084 (0x7a3fee)
        /source/routers/web/base.go:169 (0x202ac71)
        /usr/local/go/src/net/http/server.go:2084 (0x7a3fee)
        /go/pkg/mod/gitea.com/go-chi/session@v0.0.0-20211218221615-e3605d8b28b8/session.go:257 (0x145981d)
        /usr/local/go/src/net/http/server.go:2084 (0x7a3fee)
        /source/modules/public/public.go:42 (0x158ce9b)
        /usr/local/go/src/net/http/server.go:2084 (0x7a3fee)
        /go/pkg/mod/github.com/go-chi/chi/v5@v5.0.7/mux.go:71 (0x164cc0c)
        /go/pkg/mod/github.com/go-chi/chi/v5@v5.0.7/mux.go:314 (0x164e5bb)
        /usr/local/go/src/net/http/server.go:2084 (0x7a3fee)
        /go/pkg/mod/github.com/go-chi/chi/v5@v5.0.7/mux.go:442 (0x164edd5)
        /usr/local/go/src/net/http/server.go:2084 (0x7a3fee)
        /source/routers/common/middleware.go:78 (0x1e75d41)
        /usr/local/go/src/net/http/server.go:2084 (0x7a3fee)
        /source/routers/common/logger.go:23 (0x1e74fcf)
        /usr/local/go/src/net/http/server.go:2084 (0x7a3fee)
        /go/pkg/mod/github.com/go-chi/chi/v5@v5.0.7/middleware/strip.go:30 (0x1e728d8)
        /usr/local/go/src/net/http/server.go:2084 (0x7a3fee)
        /go/pkg/mod/github.com/chi-middleware/proxy@v1.1.1/middleware.go:37 (0x1e6f1d6)
        /usr/local/go/src/net/http/server.go:2084 (0x7a3fee)
        /source/routers/common/middleware.go:31 (0x1e75b99)
        /usr/local/go/src/net/http/server.go:2084 (0x7a3fee)
        /go/pkg/mod/github.com/go-chi/chi/v5@v5.0.7/mux.go:88 (0x164cbc1)
        /source/modules/web/route.go:328 (0x1e4310d)
        /usr/local/go/src/net/http/server.go:2916 (0x7a75da)
        /usr/local/go/src/net/http/server.go:1966 (0x7a2a96)
        /usr/local/go/src/runtime/asm_amd64.s:1571 (0x46ffe0)

A quick look tells me it is a bug related to the content of the Action table: for some reason the Repo field is null for these users, hence the panic. A workaround could just be to remove the content of that table (only for users with the problem) on your experimental instance and check if it helps. Newer entries will likely be populated with non corrupted content.

Don’t hesitate to PM me if you need more help: I provide Gitea services (see the message I posted yesterday on this topic).

1 Like

Hello all,
Finally this issue is resolved. But before I write the solution I would like to give my kind regards and thousands thanks to @dachary for his last message point me and my colleagues to the right direction.
So yes the issue was on the action table. All the “old” users they had as content on that table just their git commit comment. On the other hand me and an other new user (including any new test user that I have created) the contents of the action table were as a json data input, which contained our name, email, date and time and finally our git comment (I am sure I am forgetting a couple or more). In order to keep uniformity we truncated that table, however by deleting only the old data and keeping mine everything worked fine. I haven’t post anything since the last post because I(we) was trying to update the contents of all the old data to the newer json format so we could all have a history on our landing page. I failed in any given try so we end up as I said before for uniformity reasons to truncate the action table and problem solved.

Kind Regards
Chris

1 Like

How could I mark this as solved?

1 Like

Posting the solution you found as you did is the best way to mark it resolved. :+1:

I’m curious about the specifics of why it happened. Would you be willing to share the content of a few old Action rows so I can see the difference? I could try to run 1.9.6 too :slight_smile:

After taking a closer look I think it is a bug for which I proposed a fix and not data corruption of the content of the Action table. To confirm this it would be helpful to get a copy of the original database for forensic purposes to figure out exactly in which case the Action.RepoID referenced a Repository.ID that did not exist and for which user it happened. Although I was able to reproduce the problem for users with admin rights, it looks like there is another use case that leads to the same problem even if the user has no admin rights.

For the record, the gitea doctor command was improved to remove or fix the faulty rows from the Action table.

So sorry for being absent all this time. Life happens and i completely forgot to return back here and post my replies.
@dachary at this stage I do not have any “old” data from the table. However I might get something in a few days as we do keep snapshots of our systems for a month or so. Now from memory, the Action table’s columns were identical for old an new users. The only difference was on the last column named “content”. The old users had for example the following entries

Committing Changes.
Update the script.
etc

Those were the comments that they made when the commit their changes to their code.
On the other hand me and the other working user (or any new test account that I did) we had a json look entry for each commit, looking like

{ 'email': 'user@domain.com',  'user' : 'Joe Doe', 'comment': 'Fixing firewall', etc }

I am writing this away from the office so please forgive my inaccurate findings, but give or take that’s how the entries looked like. The comments of the old user where entered without any quotes . Pure strings.
If you wish me to post more accurate entries please allow me a few days, or perhaps early next week.
Kind regards
Chris

1 Like

Thanks for the update. These changes are handled properly and won’t cause a problem. An improvement was made a few days ago to the gitea doctor command. When 1.16.8 or 1.16.9 is released it will be possible to run gitea doctor --fix --all to get rid of the problematic Action record or fix them.